Re: Hurd IPC

[Neal H. Walfield]

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

Exactly.

> 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.

I do not with this.  We certainly want to be microkernel independent
but that does not mean that we should not take advantage of the
primitives provided by any particular.  I want to stress that the
*implementation* of the Hurd IPC interface is not terribly important;
it is the interface which we need to be consistent: using microkernel
specific features can easily be hidden using some type of sysdeps
structure as found in, e.g. glibc.

> 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.

Define using them directly: a typedef will solve this problem.

> 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. ;)

We will use ports on Mach.  There is no other way to do IPC
efficiently.