Topic for discussion: OS Design

From: Dwayne C . Litzenberger (dlitz@dlitz.net)
Date: Sun Oct 22 2000 - 17:29:19 EST


First of all, I'd like to say that I'm not writing this to piss anyone off.
It's not a flame, a troll, or a personal attack on anyone. I my writing will
aid in the improvement of Linux. Please read this with as much neutrality as
you can summon.

Although I am a programmer, I am not yet a kernel hacker, so some of my claims
may be false. Feel free to correct me.

"Practice what you preach; don't preach what you practice."

A few years ago, there was an intense debate around the question of
cooperative vs. preemptive multitasking operating system design. Today,
however, cooperative multitasking is a thing of the past, and it is virtually
undisputed that the preemptive multitasking design is highly superior to the
cooperative one.

What's the difference? Well, operating systems employing cooperative
multitasking are no longer in the mainstream. There is no longer a need to
pointlessly defend the status quo.

Linux's loadable modules design is insufficient. I have several reasons for
making this claim:

1. Many things are inaccessible to the modules: There are relatively few
kernel modifications that can be compiled without patching the pristine
sources.

2. The modules API is unstable. Some people say this is because of the
exceedingly rapid development cycle of Linux. I beg to differ. I believe it
is because there is no real planned structure in the API -- just passing
highly volatile internal data structures around.

3. Modules can very easily crash the whole kernel. This is because each
module does not get to run in its own protected memory space, as it would in a
well-designed microkernel.

4. The kernel HTTPD is just masking a slow networking design. Yes, I agree
that high-level protocols should be eventually incorporated into a
standardized interface in an operating system. However, there would be no
need for a kernel-based httpd if the kernel was efficient enough. This leads
into my next point:

5. Linus tends to blame patches for inadequacies in the kernel. The PC
speaker driver is a perfect example: No driver should have to do something
"dirty" in order to function, because the operating system should provide
clean ways to do this.

It would seem that a microkernel design would fix most of these problems. Two
very elegant operating systems, namely the Amiga's exec.library and QNX's
Neutrino (I'm sure you can name others), used microkernels, and they were both
*very* efficient. However, there are some drawbacks to microkernels that have
been raised (and I don't have the expertise to argue about them), but I think
there are enough intelligent people here that we can come up with a new OS
design that takes the best from both worlds. This may require a new mailing
list.

So, my question is this: What are some of Linux's design problems, and what
fundamental changes could be made for a long-run benefit?

-- 
Dwayne C. Litzenberger - dlitz@dlitz.net

- Please always Cc to me when replying to me on the lists. - Please have the courtesy to respond to any requests or questions I may have. - See the mail headers for GPG/advertising/homepage information.


- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:19 EST