Re: Hurd IPC

[Ludovic Courtès]

On Fri, Oct 11, 2002 at 08:16:18PM -0400, Neal H. Walfield wrote:
> That was never my intention.  The Hurd should not require Mach
> semantics, however, there is not reason that it should not use them to
> meet its requirements.  In the Hurd, the primary users of ports are
> libports and glibc.  To understand the actual requirements, we must
> understand what these applications are currently doing with ports.
> The short answer is managing handles to objects; the handles just
> happen to be ports.

Neal: Thanks for your explanations.

The Hurd on top of L4 will need to have its own "handle management server",
and I guess that would be the same for other second-generation micro-kernels
such as Fluke. This means that all occurences of Mach ports and ports
management functions in libports, glibc and the likes should be replaced by
handles and RPCs to this 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.

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?

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. However, this 
would
guarantee that the Hurd is actually micro-kernel independent. [1] describes
the implementation of such a "communication channel abstraction" on top of
Mach ports, with a user-level communication management server (called "Port
Authority").

Thanks,
Ludovic.

[1] http://citeseer.nj.nec.com/goldberg90transparent.html