*long explanation alert*
Ok, I think the L4 stuff needs a bit of background. Special for Niels: I started doing a Sparc port, but there were some problems which are similair to those that the Alpha port has, so that's why I react. (oh, and I have an Alpha, so I'm also interested in the Alpha port :) On Mon, Oct 30, 2000 at 11:04:02AM +0100, Niels M�ller wrote: > (I believe managing send rights is a sane way to deal with security in > a complex system. So I don't think it is good enough to just try to > change the HURD's model to fit L4; after all, one of the points of > the Hurd-L4 thing is to make the HURD less dependent on particular > micro-kernels. To do that, one need to identify the features that are > essential to the HURD, and find out the best way to get them on each > kernel one is interested in). This is precisely the problem with GNUMach, and why I've made little progress in porting HURD to any microkernel on Sparc. The Sparc I have has SBus as primary bus, so no ISA/PCI or other PC bus. For this I tried to disable *all* the device drivers (not the service, but the drivers itself). This is not trivial, because there are actually two sets of drivers: the Linux ones and the Mach native ones. The other thing I did is seperating and cleaning up the header files and directory structure. Note: this is in my private copy, and I don't know if I will ever commit it to CVS. You might see this as basic research on how GNUMach works (ie: what depends on what, where is what and how does it fit/work together). Now we have the Alpha team which is also porting HURD on some microkernel. Their specific problem is that the drivers which are currently in GNUMach are quite outdated and have poor Alpha support. I've followed the changes to the GNUMach CVS repository, and there appears to be very no work on drivers. This is understandable: it works well, also on my PC. So, for any port to be done, the drivers do need work. Along the way I (and obviously others) stumbled across the L4 family, which has one eye catching difference: it is *far* more modularized than GNUMach. One of the consequences is that there are no device drivers in L4. Those should be an add-on service, just like HURD is an add-on service. Now my opinion is that GNUMach would improve if the driver portion would be removed and made a seperate service. One consequence is that GNUMach needs to be modified to support more servers. So for porting there is the actual kernel left. The question is quite simple: is it better to modify GNUMach to run on Alpha, or take L4 (which runs on Alpha and has SMP support) and implement something like a GNUMach server? The answer is quite hard, and I don't know it. To conclude: What I'd like and plan to do is to seperate the drivers from GNUMach to simplify porting. For Alpha this means that they can use this driver service, but still have to write the GNUMach server. For Intel this means updated drivers. For Sparc this means that I have the choice of porting GNUMach or porting L4, depending on how the work on Alpha goes. This is also where my programming effort goes to at the moment. Well, I think that's all. Erik. -- Erik J. Verbruggen, [EMAIL PROTECTED], Daneel on IRC, room A5005 science faculty KUN, phone: +31-24-3652229
