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" :))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 23 2002 - 22:00:25 EST