Re: L4Mach or Refactor Hurd Servers?

[Farid Hajji]

> > Basically, it proved difficult to emulate the complete Mach API. If you
> > want to implement L4Mach, it will most likely provide just a subset of
> > Mach, so that we can get the Hurd up and running (in a first step).
> Making the Hurd run on L4 should be done by porting it.  Making L4
> emulate Mach, in part or in whole, is probably a waste of time.
Agreed.

> > The most difficult issue is IMO how you want to handle asynch. IPC,
> > especially the notifying mechanism. In the Hurd, you need at various
> > parts to detect/receive something called "dead port notification".
> > Emulating this on top of L4 (with or without the help of a L4Mach
> > server) may be difficult, but I'm not sure yet.
> 
> Do you mean dead name notifications, or no-senders notifications?  The
> former are not so important.  The latter are very important.
You're right. I meant no-senders, not dead-name notification.
Sorry for the confusion.

> > This is the most important question regarting the port. If the Hurd had
> > been designed with other microkernels in mind, it would have certainly
> > been more restrictive on its use of mach-specific IPC-ism. 
> 
> We *have* been so restrictive.  The need of no-senders is quite
> inherent; if you understand what we use them for, it's clear that any
> system simply must provide a similar function, whether "asynch" or
> not. 
>
> Thomas

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.