Re: Hurd IPC

[Ludovic Courtès]

Hi!

> There will be no central server; there is no need for one as the
> servers can do all of the handle management themselves.  I tried to
> suggest that in my previous email.

Right. After re-reading your email, my understanding is that "knowledge of the
open communication channels would be distributed": IOW, if A is talking to B,
A and B are the only one to have information about it (the server keeps a
tuple as described in your email and the client only keeps a "handle").

So, with such an architecture, no information about communication channels
need to be held by the kernel, nor even by one server.

> > Moreover, as L4 only supports synchronous
> > message passing, it may be necessary to implement an asynchronous mechanism
> > (with message queues and so on) in user-space.
> 
> I cannot think of any cases where we need this type of functionality,
> what do you have in mind?

Nothing special. I don't know if it is a desired functionnality. I just wanted
to point out that in case it was needed, it should be possible to implement it
in a generic way on top of any microkernel -- on Mach, this implies that we
should not use the facility provided by the kernel. The goal is, as Marcus
stated, to be able to have the same the same client and server code whatever
the kernel is, i.e. the least micro-kernel dependent code.

> libports already has the required abstractions.  There are only about
> a half-dozen functions which need to be changed significantly.

The problem is that on Mach, unlike on the Hurd for Fluke or L4, we use
"ports", which are a kernel built-in facility. My point of view is that we
should try to ignore these built-in facilities and use Mach as if it were a
second-generation microkernel. For instance, we should not use mach_port_t
directly. Instead, we could implement the mechanism you described, where
servers are able to manage themselves the handles they deliver.  However, at
some point, these handles have to be bound to a port since this is the only
communication mechanism offered by Mach.

Actually, my concern is more about persistent systems. :) In order to build a
persistent system, the less information resides inside the kernel, the better.
On Mach, the ports mechanism is a problem since it is entirely managed by the
kernel. Beside portability, this is a second good reason to not use ports
directly. ;)

Thanks,
Ludovic.