Re: mach deficiencies
> The point is that there has been considerable research done since Rashid
> left for Microsoft, particularly with L4 at Dresden University, concerning
> microkernel performance, thereby showing up more clearly some of the
> advantages and disadvantages.
Not to imply that just because something is written in assembler means
that it's always smaller and faster, but, it's written entirely in
assembler! Of course it'd be small and fast. :)
(Unless I'm missing something)
> Note that:
> a) L4 is actually a small microkernel;
> b) OSKit has been showing off that it is useful to create an OS
> infrastructure surrounding memory allocation schemes in order to be
> supportive of specialized languages;
> c) Most early microkernels seem to have been monolithic systems, unlike
> Hurd.
I think that theoretically, the Hurd would be much better off ditching
GNUMach for L4, but there's a lot stopping something like that.
We're effectively throwing away a lot of work by ditching GNUMach. It
is always smart to get rid of something that isn't working NOW than it is
to wait awhile until you're positive that it isn't working, but it's
difficult to go on something like that because not everyone agrees that
GNUMach isn't working. Although it seems that way so far.
The L4 project pages mention their difficulties trying to port servers
that use a Mach interface to their kernel. Who feels like rewriting the
Hurd's servers? :)
We'd also either have to write new glue code for the drivers, or ditch
them altogether and start with new ones.
There are arguably lots of good things from switching to L4 too. A
microkernel that is actually micro! More speed, perhaps. Sanity of
maintainance, definately. Cleanliness of code, maybe.
Possibly some better publicity for switching, because we's need people!
But, I have no status here, so I can shut up now.
--Michael Bacarella
Reply to: