On Sun, Aug 17, 2003 at 05:27:32PM +0100, Mark Wilkinson wrote: > If the decision has been made to go to L4, IMHO work should have halted > on Mach.
People have halted on Mach long before L4 even entered the picture. > Forgive my ignorance, but why is L4 3-5 years away? L4 was released a month ago or so. But it is not a drop in replacement for Mach. > If the > decision has been made to move to a kernel structure that doesn't exist > yet, that strikes me as an *interesting* decision. The L4 kernel is truly minimal. The Hurd depends on a couple of features in Mach that simply don't exist in L4. The three core issues: * Device drivers * Virtual memory management * A capability based IPC system L4 does not have any device drivers. Some people are working on a new device driver infrastructure for GNU Hurd/L4, and drivers for that infrastructure. It's a huge task, but it is also an interesting challenge. Device drivers will be in user space and thus can be multi-threaded. This allows to keep state about a device active in the thread, and can greatly simplify a driver. L4 does not have any Virtual memory management, just some primitives to recursively map pages into other address spaces. The physical memory is provided directly to the user space. So we have to implement a VM system. Neal has some great and ambitious ideas about doing VM management locally in every task, instead of a global server. This is a dramatic departure from traditional OS design (even from Mach and the Hurd as it is now), and thus needs to be fleshed out from scratch (there are some academic papers on it, but I don't know of a production system doing it this way). L4 provides a minimal IPC system, that allows direct thread-to-thread message sending. But it only gives a single protection primitive. So it is not usable for a user space multi server system as the Hurd, where untrusted communication is happen on a frequent basis. This is why a more featureful capability system is needed. Instead doing it in a central global server (like the port system in Mach is centralized), we want, again, do it locally in each task. This seems to be a new design to me, and I have worked on the protocols and data srtuctures for that in the last weeks. I am currently working on an implementation, which is needed very early in any porting effort to L4. So you see, it is not about L4, but about glueing Hurd to L4. Mach did a lot of things for us that L4 is not doing, and we take the chance to try to more consequently implement the Hurd's fundamental design ideas. Freedom to the users! Freedom to map your physical memory as you want it, freedom to use the IPC policy you want, and the freedom to have functional device drivers without getting them approved by a kernel master geek ;) Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org [EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
