Hi Ondrej, > I suppose that's the point of L4. Features needed by Hurd must be > implemented in the mk abstraction layer of Hurd. Do you think there > are some areas that are not easy to be implemented efficiently on L4 > ? please look at recent archives of l4-hurd for the current status.
> If your goal is layer very similar to some subset of the Mach API > (i.e. Mach emulation in fact) > then it is only matter of writing some typedefs, constants, wrapper > routines/macros, > putting them into a few header files and replacing all Mach stuff > with them. > Seems easy but it has to be done and I was just wondering if somebody > actually plans this or not. As already discussed on l4-hurd, writing a complete (or btw. even a partial) mach emulation may not be the best solution. Some things in VK/L4 will emulate certain aspects of Mach behaviour quite closely, then again, others may not. One good example is how to implement vm_*() functions in VK/L4: The consensus for now seems to be that we need a user-land pager running on top of L4 which will serve pages through a yet-to-be-agreed-upon protocol. This protocol will be implemented with IDL stubs and a support library would then provide vm_*() calls to client tasks on one side and RPC the pager on the other side. At the moment, I'm advocating that we implement this pager using NetBSD's UVM kernelpager. So, if we have this pager, calls to Mach's VM (and idirectly to its default pager) will simply be rerouted thru this vm-library. The consequence is that no changes to the Hurd code base will be necessary (at least for VM stuff). Another example are device drivers. We (l4-hurd) are investigating two alternatives: OSKit maintained drivers and the L4Env environment that must still be released by Dresden University. In any case, it will be probably easy to provide glue code that will mimick Mach's device framework dev_*() functions. Here again, I expect no necessary changes to the Hurd's codebase. The most difficult part in the l4-hurd port right now is how to map Mach IPC to L4 IPC. Mach IPC is basically asynchroneous, whereas L4 IPC is synchroneous. Current status in the discussion on l4-hurd is this: Most of the Hurd calls can be made synchroneous. There is _mostly_ no need for asynch. communications (I'd suspect in more than 95% of the cases, but that is more of a wild guess than anything else). This portion of synchroneous calls can be implemented quite straigtfully by an IDL compiler which will convert *.idl files to L4-IPC. At least two such IDL compilers for L4 exist and for Mach, we have flick-1.x, which also supports L4 as backend. So the Hurd people will need to first migrate from MIG to, say Flick/Mach and provide IDL files instead of the current MiG *.defs. Then we can hook in one of the L4 IDL compilers to generate the synchroneous IPC stuff. The current problem with IPC is how to obtain no-senders notifications in an L4 environment: In the Hurd, the servers (or more exactly, the stubs) need to know when a port is dead a.k.a. when it can be sure that no clients will ever send an IPC down this port, so that it can clean up resources. The obvious scenario is when a task dies and so a translator will have to release all open fileresources of this task. There is no such mechanism in L4, so it will have to be implemented as a user-level task (basically, a task-server that 'owns' the tasks it creates and than will provide for notifications upon tasks deaths to registered clients). Once we've sorted out those things, changes to the Hurd codebase will be needed (but only then). Those changes would be mostly cosmetic in nature, (calling vk_*() functions instead of mach_*()), as well as using a hopefully portable IDL compilers for normal IPC. The issue of Pthreads vs. Cthreads will then also have to be dealt with. I expect that future versions of L4 will provide enough native threads so that a 1:1 pthreads library can be used rather directly. Sure, things like signal handling in glibc will have to be coordinated with this L4- pthreads environment, but we're not yet ready for this. BTW, the L4 people are currently in the process of specifying a new API revision of L4 (Version 4) which will also provide a standardized set of C-Bindings and other improvements. l4-hurd is very far from dead :-) > Ondrej Regards, -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.
