Re: Comments on the hurd-on-l4 document

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> great to see you still being interested and your input is as always
> appreciated.

Thanks. I'm browsing the list archives from time to time, to try to
see what's happening.

> Before diving into the details eventually, I want to
> give you a head start that under the surface there are some radical
> changes going on that are not reflected anywhere, not in the docs, not
> in the source, and also not on the mailing list.

Ooops ;-)

> The most important changes are related to the capability system.  I am
> convinced by now (and I think Neal agrees) that we simply can not
> feasibly implement a capability system without support by a central
> authority, either the kernel via its IPC system, or a trusted
> capability server.

It's still appealing to be able to do it with rudimentary kernel
support and all the rest locally in each task. But if the kernel
doesn't provide sufficient support, I guess the L4 way is to introduce
a central userspace server to do it (i.e. we have to figure out what
we would really like the "kernel" to do for us, and then implement
that "hurd kernel" as L4 + a bunch of extra servers).

Would all ipc go via the capability server (that would have quite
severe performance implications), or will it be used in some other
way?

> I can not pinpoint this on a single killer argument.  There are a
> couple of things, among them:

> * In upcoming L4 designs, global thread IDs will be _gone_, and our
>   design will not carry over without some fundamental changes anyway.

This sounds odd. When you want to send an IPC to a thread in a
different address space, how do you tell the kernel which thread you
intend? What you say seems to imply some kind of per-address-space
table that maps of user-space id:s to some kernel thread objects,
right?

> * Capability transfer requires too much trust.  We should be able to
>   accept capabilities even if they come from untrusted sources.

Yeah, that's a severe limitation.

> The capability transfer mechanism I designed is a pure nightmare (I
> have a race-free design, and it is horribly complicated, and can
> hardly be optimized at all).

It looked ok to me; I think it's a good tradeoff to make capability
transfer somewhat expensive and complex, if we gain performance for
the much more common operation of *using* a capability.

> * Task info capabilities are just an insane concept to go with in the
>   first place.  They are a sad excuse for a real capability and/or
>   notification server.

What we really need is a stable identifier for a communications
partner. The problem with thread and taskid:s is that they can change
meaning out of control of the tasks relying on the id. Task references
is one way to deal with that. A purely local namespace, mapping local
id:s to kernel objects, is a different solution. Mach ports are really
such an id + a message queue; I just hope the L4 counterpart is more
light weight...

> So, instead we are now looking at capability server designs and what
> type of kernel extensions are necessary.  It seems that only a very
> small extension to upcoming L4 designs may be necessary, but it
> depends a lot on the exact details, so we try to talk to everyone
> about it.

Is there any information available about the "upcoming" L4 design?
>From what I recall of vague earlier discussions, it would be neet to
have some L4-"capabilities", where a capability simply means the
ability to send a message to a particular thread, with some way of
mapping or granting such capabilities to other tasks. As usual, we'd
also need some way to implement no-senders notifications to the
receiving end of a capability and (maybe less important)
death-notifications to the sending ends. It's highly desirable to keep
any central capability server out of the common case communication
path.

> About notifications: My current stance is that they are fundamental,
> and have to be done right.  Instead of minimizing their use, I tried
> to imagine what we could do if we had good notification support.

Cool. Notifications were an important part of the original Hurd
design, and I always felt a little uneasy about the "all-ipc-is
synchronous and blocking". I think performance is less important for
notifications than for general capabilities, so it should be ok to use
a central server for that. But note that a notification server which
also queues messages is almost the same thing as a server implementing
Mach ports...

To sum up, from the clues you give me, it seems like you want a
heavy-weight almost-mach port concept for notifications, and a lighter
form of ipc directly between tasks/threads, that relies on some
lightweight and so far non-existing capability mechanism in L4.

Best regards,
/Niels