>>>>> "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/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:19 EST