Re: Hurd IPC

[Ludovic Courtès]

Hi,

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

I consider Mach as being a particular case: It's probably the only
micro-kernel the Hurd will use that have this kind of specific features
(ports). Tell me if I'm wrong, but most second-generation kernels work pretty
much like L4 (anyway, there are not so many of them I guess).

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

Sure. But when I say that we could try to use them "not directly", I mean we
could have an abstraction binding ports to our own abstraction. This is
different from a typedef. For instance, while the client code would just
manipulate handles (i.e. integers), glibc (e.g. in file_name_lookup ()) could
keep more information related to these handles such as the server path and the
port currently use to communication with it.

There's actually one point that's still not very clear to me about the IPC
model you described. You said the client would *only* keep the handle. Now, if
the client does an open on two different servers and both of them return the
same handle (the same integer), how can the client differentiate between them
in further communication?

Thanks,
Ludovic.