Re: [ANNOUNCE] Introducing Codezero

[olafBuddenhagen]

Hi,

On Mon, Jul 13, 2009 at 10:47:37AM +0300, Bahadir Balban wrote:

> I don't have a goal of implementing the ultimate microkernel desktop
> system. My focus is on embedded systems.

Well, you certainly made your original post sound like if you believe
your work is compatible with the Hurd goals; but now you admit that it
actually isn't...

> But I can argue that L4 is the best candidate for a microkernel based
> OS in general. The reason is simple. L4 is very well engineered. It
> provides the leanest mechanisms that are made available by the
> underlying hardware. You can build up anything on top of it. Security
> systems, Object-based capability systems, distributed systems, etc. in
> my view it's all a matter of writing the relevant C code on top.

Not really. Shapiro has put it pretty well: one of the L4-based projects
(don't remember the name right now) showed that it *is* possible to
build such a system on top of L4 -- but only at prohibitive costs...

This confirms our own conclusions from the Hurd/L4 experiment:
implementing capabilities in user space on top of L4 requires a lot of
effort and introduces a lot of overhead.

> A user program is granted a capability as above from an authorization
> server. The capability is most likely one that allows communication
> with a service. The service obtains a copy of this capability from the
> auth server, and whenever the user program calls the server (it also
> has an ipc capability to it) the server checks the request from its
> capid, and either accepts or refuses to take it. So capability
> validity checking is distributed to those resources that are involved
> in the capability.

This is not really realistic. For one, it allows for DoS attacks, unless
you can somehow guarantee that the resource usage of the validity check
is accounted to the client -- probably possible, but quite tricky.

And then there is the overhead.

> It seems like in a simple model as above, you can dynamically pass
> along capabilities, check for capability validity, and yet, the
> microkernel is free of any of this burden, such that, say, a set of
> lightweight, no-capability, threads may run in isolation in a separate
> L4 domain without having a clue of what's going on on the other side.
> (Let's say we have a separate DSP processor that needs an efficient
> multi-threaded driver that needs to communicate with nobody)

EROS has proven that kernel-based capabilities can be implemented with
no noticable overhead... So this exercise is really pointless -- once we
have a capability-enabled kernel, there is no reason to avoid using
them.

> I don't particularly see a necessity for writing a completely new
> microkernel with the argument that L4 cannot incorporate capabilities.

Lack of capabilities is not the only problem with traditional L4. The
purely synchronous IPC for example also turned out problematic, as well
as the fact that the kernel allocates memory on behalf of user
processes.

Experience shows that microkernels are not really reusable, except for
systems with very similar requirements. The requirements of the Hurd are
very different from those of typical L4 use cases. Viengoos is partially
based on L4 ideas, but specifically designed to fit the requirements of
a system like the Hurd -- anything more similar to the traditional L4
will probably have some shortcomings for us...

-antrik-