Re: Hurd IPC

[Neal H. Walfield]

> The Hurd on top of L4 will need to have its own "handle management
> server",

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.

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

> All these features are natively supported by Mach with the ports abstraction.
> However, do you think that each port to a new microkernel should lead to the
> creation of a new branch of the Hurd libs? Or do you think that once this
> server and the related mechanisms are implemented for L4 we should also try to
> implement them on top of Mach so that the Hurd remains the same, whatever the
> underlying kernel is?

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

> I guess implementing such IPC mechanisms on top of Mach, i.e. using Mach
> ports, would be very unefficient -- but the long term plan is probably not to
> keep Mach when there is an L4/Fluke implementation available.

I do not see why it should be any more or less efficient than it is
now.  The Mach ports abstraction provides everything we need.  In
fact, it provides more than we need which is one reason that we do not
want to just clone it on other microkernels: the extra functionality
which we do not use is costing us a lot in performance.

The IPC abstraction that I have come up with does not change the Hurd
IPC model in any significant way.  The exercise was to determine
exactly what primitives the Hurd uses and requires and then to try and
separate them from Mach IPC semantics; I am *not* suggesting a
completely new IPC model.