Linux, the microkernel (was Re: latest linus-2.5 BK broken)

[Jeff Garzik <jgarzik@mandrakesoft.com>]

Larry McVoy wrote:
> the first place.  It's proactive rather than reactive.  And the reason
> I harp on this is that I'm positive (and history supports me 100%)
> that the reactive approach doesn't work, you'll be stuck with it,
> there is no way to "fix" it other than starting over with a new kernel.
> Then we get to repeat this whole discussion in 15 years with one of the
> Linux veterans trying to explain to the NewOS guys that multi threading
> really isn't as cool as it sounds and they should try this other approach.


One point that is missed, I think, is that Linux secretly wants to be a 
microkernel.

Oh, I don't mean the strict definition of microkernel, we are continuing 
to push the dogma of "do it in userspace" or "do it in process context" 
(IOW userspace in the kernel).

Look at the kernel now -- the current kernel is not simply an 
event-driven, monolithic program [the tradition kernel design].  Linux 
also depends on a number of kernel threads to perform various 
asynchronous tasks.  We have had userspace agents managing bits of 
hardware for a while now, and that trend is only going to be reinforced 
with Al's initramfs.

IMO, the trend of the kernel is towards a collection of asynchronous 
tasks, which lends itself to high parallelism.  Hardware itself is 
trending towards playing friendly with other hardware in the system 
(examples: TCQ-driven bus release and interrupt coalescing), another 
element of parallelism.

I don't see the future of Linux as a twisted nightmare of spinlocks.

	Jeff



(I wonder if, shades of the old Linus/Tanenbaum flamewar, I will catch 
hell from Linus for mentioning the word "microkernel"  :))