Re: L4Mach or Refactor Hurd Servers?

[Niels Möller]

Ian Duggan <ian@ianduggan.net> writes:

> I dug around some and found this document describing the Spring OS
> system (Sun research kernel). Spring wasn't adopted, apparently
> because Sun's customers were pissed off about the pains of switching
> from SunOS to Solaris,

Hmm. My understanding is that Spring was a research project, never
intended to be released to real customers. Instead, the experience
from it was used when doing Solaris. So that Spring preceded Solaris.
Looking at the references in the overview I'm reading, it seems many
Spring papers were published in -93, so I guess most of the work was
done about ten years ago. But I don't really know the history.

> A key thing to note, it looks like Doors is similar to Mach ports in
> that it is handled in the kernel. We could of course try to mimic that
> with servers, but that is at least one important difference.

I guess there are two important problems that need to be addressed,

* Security, you should only be able to talk to the threads/port/door
  that you you have permission to talk to. L4 security seems to be a
  moving target, with the chiefs-and-clans-model being abandoned.

* No-senders notifications. Without that, we'll end up with something
  like w*ndows COM: when any client or component crashes violently,
  the rest of the system can't clean up after it.

Both needs some system support, be that in the kernel or in some
special server. Having a single server responsible for all port
rights/door handles is a little against my intuition (in particular if
that server get's involved on every or most of the rpc calls), but
perhaps that's the L4 way. Unless the L4 folks add some more useful,
capability like, security mechanisms to the kernel.

It would be interesting to hear some more about the Fluke approach to
these problems (that which Roland mentioned a few messages back, in
<20011106040723.DCFE299809@perdition.linnaean.org>).

Regards,
/Niels