> > 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 | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
