Messages in this thread |  | | Date | Sun, 22 Oct 2000 16:29:19 -0600 | From | "Dwayne C . Litzenberger" <> | Subject | Topic for discussion: OS Design |
| |
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. [unhandled content-type:application/pgp-signature] |  |