[okl4-developer] OKL4 and timer service.

Gernot Heiser gernot at ok-labs.com
Wed Sep 9 19:00:22 EST 2009


>>>>> On Wed, 9 Sep 2009 10:13:34 +0200, Christophe Augier <christophe.augier at gmail.com> said:
CA> Hi Gernot,
CA> I see, you're still talking about this principle of minimality in
CA> microkernel in general and in okl4 in particular. I would like to take
CA> the opportunity to ask you why did you introduce mutexes, capabilities
CA> and finally cells in the "microkernel" as it goes against this
CA> principle of minimality ; as such is okl4 still a microkernel? or is
CA> it why you introduced the microvisor term.

Caps are minimal: they are object references and imply access
rights. Both are needed, and neither functionality is provided by any
other mechanism. And they are much more powerful than the mechanisms
that previously provided that functionality, as they provide
finer-grained access control, provide a clean model for privilege
delegation, and avoid the covert storage channel introduced by global
names.

Cells are in fact a higher-level construct, they don't exist in the
kernel. They are implemented by the (minimal) kernel mechanisms of
caps and clists.

Mutexes can, in principle, be implemented at user level, but with high
cost. The reason is that an efficient implementation needs to interact
with scheduling. (And I'm not sure whether prio inheritance could be
even implemented at user level, as long as the scheduler itself is in
the kernel.)

As long as we don't find a way to export scheduling completely to user
level (without significant performance degradation) this is probably
unavoidable.

Having said that, we do in fact at times compromise minimality in some
places, generally to enable a smooth transition to new
functionality. That's a legacy issue that is unavoidable with a system
used in real-world products. But we're doing our best to keep this at
a minimum, and remove redundant features as we can.

Gernot



More information about the Developer mailing list