Messages in this thread |  | | Subject | Re: Topic for discussion: OS Design | From | Jes Sorensen <> | Date | 23 Oct 2000 00:57:10 +0200 |
| |
>>>>> "Dwayne" == Dwayne C Litzenberger <dlitz@dlitz.net> writes:
Dwayne> First of all, I'd like to say that I'm not writing this to Dwayne> piss anyone off. It's not a flame, a troll, or a personal Dwayne> attack on anyone. I my writing will aid in the improvement of Dwayne> Linux. Please read this with as much neutrality as you can Dwayne> summon.
Oh my, not another one of those ;-(
Lets try and kill this on on the rise and avoid another flame war caused by someone who hasn't tried to write single line of code on his own.
Dwayne> Linux's loadable modules design is insufficient. I have Dwayne> several reasons for making this claim:
Dwayne> 1. Many things are inaccessible to the modules: There are Dwayne> relatively few kernel modifications that can be compiled Dwayne> without patching the pristine sources.
Your point being?
Dwayne> 2. The modules API is unstable. Some people say this is Dwayne> because of the exceedingly rapid development cycle of Linux. Dwayne> I beg to differ. I believe it is because there is no real Dwayne> planned structure in the API -- just passing highly volatile Dwayne> internal data structures around.
And this is a good thing, we want an efficient API not something that people are afraid to break in order to solve problems - if we have a bug or we can improve the API we should improve the API. Yes you can claim you can design your way out of everything and everybody who's written real code knows thats not the case. Code and design is an iterative proces.
Dwayne> 3. Modules can very easily crash the whole kernel. This is Dwayne> because each module does not get to run in its own protected Dwayne> memory space, as it would in a well-designed microkernel.
Oh my, did you just take the first lecture in a junior OS course? Putting them in their own protected memory space is a) similar to putting things in user space except for interrupt handling and b) very inefficient for passing data around inside the kenel. The next lecture in your course should cover context switches and page table modifications and the cost of these.
Dwayne> 4. The kernel HTTPD is just masking a slow networking design. Dwayne> Yes, I agree that high-level protocols should be eventually Dwayne> incorporated into a standardized interface in an operating Dwayne> system. However, there would be no need for a kernel-based Dwayne> httpd if the kernel was efficient enough. This leads into my Dwayne> next point:
Which kernel httpd? tux or khttpd? Tux is designed for the specweb pissing contest, thats what specweb is all about. khttpd should be replaced by something like phttpd which is a sigio based web server. The performance has little to do with the networking design.
Dwayne> 5. Linus tends to blame patches for inadequacies in the Dwayne> kernel. The PC speaker driver is a perfect example: No driver Dwayne> should have to do something "dirty" in order to function, Dwayne> because the operating system should provide clean ways to do Dwayne> this.
A lot of drivers are badly designed and a lot of hardware is badly designed, in particular PC hardware ;-( I don't know the details on the PC speaker driver, but it is clearly something dear to you.
Dwayne> It would seem that a microkernel design would fix most of Dwayne> these problems. Two very elegant operating systems, namely Dwayne> the Amiga's exec.library and QNX's Neutrino (I'm sure you can Dwayne> name others), used microkernels, and they were both *very* Dwayne> efficient. However, there are some drawbacks to microkernels Dwayne> that have been raised (and I don't have the expertise to argue Dwayne> about them), but I think there are enough intelligent people Dwayne> here that we can come up with a new OS design that takes the Dwayne> best from both worlds. This may require a new mailing list.
And if you had done your homework you would also know that exec.library is based on running in a single shared memory space. There is a reason why micro kernels are practically dead.
Dwayne> So, my question is this: What are some of Linux's design Dwayne> problems, and what fundamental changes could be made for a Dwayne> long-run benefit?
Actually one of the biggest problems we have is the noise ratio caused by people not doing their homework and then raising issues on the list expecting everybody to take them serious.
Jes - 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/
|  |