l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ANNOUNCE] Introducing Codezero


From: olafBuddenhagen
Subject: Re: [ANNOUNCE] Introducing Codezero
Date: Wed, 4 Nov 2009 06:38:45 +0100
User-agent: Mutt/1.5.19 (2009-01-05)

Hi,

On Sat, Jul 25, 2009 at 07:36:11PM +0300, Bahadir Balban wrote:
> address@hidden wrote:
>> 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...
>
> What I see in Hurd is a multi-server POSIX compatible OS core based
> around a truly microkernel design.

Hurd is much more than that. Your description sounds more like Minix3.

Also, the focus on embedded (again like Minix3), automatically makes it
a very different (and much easier) design.

>>> But I can argue that L4 is the best candidate for a microkernel
>>> based OS in general.
>>
>> 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.
>>
>
> This claim was probably made with many assumptions that narrowed down
> the example case to produce a negative result. In other words, perhaps
> the way it's design was anticipated was costly. I always think there
> can be a new perspective.

Well, you are right in a way: we can't exclude the possibility that
those who tried it so far just didn't try hard enough... But the burden
of proof is on you here :-)

> Having all capabilities maintained by the microkernel will add policy
> to it and inflate it, so it will somewhat deviate from a rigorous
> microkernel design.

That's not true. An IPC mechanism with capabilities for the
communication ports doesn't really add any more policy than an
unprotected IPC mechanism. The policy is implemented in user space, by
deciding who gets which capabilities.

Also, if done right, the amount of complexity added to the kernel is
pretty small.

> However, a significant goal in Codezero is to remain generic for
> building any OS core on top.

Again, this is not possible. Different system have different
requirements for the microkernel. If you fail to understand that, the
discussion is pointless.

> Capabilities would be sent to the server during mounting of the server
> as a service or during open(). From that point on, each request is a
> single call to the server.

No, capabilities have to be checked on *every* IPC. That's the whole
point: we need to make sure that requests can only be made by authorized
clients.

> It is trivial to implement asynchronous messaging in L4, and I agree
> that there are occasions where it is necessary.

No, you can't just graft on such a fundamental thing upon an existing
design. The reason microkernel design is so hard, is because every
single decision you make influences many of the others.

> In latest L4 designs (and in Codezero) the kernel does not allocate
> for userspace.

Partially asynchronous IPC doesn't require kernel allocation. The
receiver can allocate a buffer up front, and the kernel stores the
message there; then the receiver processes it asynchronously.

This removes the requirement for having a distinct thread listening on
every single receive port for possible requests, when implementing
system calls like select().

Obviously you haven't ever looked at what Viengoos does.

> From this discussion I see that the only major difference is managing
> userspace capabilities inside the microkernel.

No, it's not. And as you haven't even looked at Viengoos, you are not in
a position to make such a comparision.

> I am interested in Hurd because originally my idea of building a solid
> microkernel-based OS closely relates to Hurd goals,

"solid microkernel-based OS" is not very specific -- there are many
systems that try to be that; and in the embedded market, there even
already are several that succeed. General purpose systems are *much*
harder though.

Also, being microkernel-based is not strictly a goal of the Hurd. It's a
means -- to speed up development (well, originally -- we know by now
that this was an extremely misguided decision...); and to provide a
user-extensible system environment.

-antrik-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]