"Dwayne C . Litzenberger" wrote:
>
> 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.
And please search the kernel list message archives before posting stuff
like
this. People here are smart, and the reason they don't discuss your
ideas are because they were all discussed some years ago, everybody
agree on the conclusions, and don't want to discuss the same things
again
just to please a newbie. Search the archives - the answers is there.
>
> Although I am a programmer, I am not yet a kernel hacker, so some of my claims
> may be false.
Good that you acknowledge this. Kernel programming is different from
other programming, so usual software design rules does not apply.
> "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.
Yeah, cooperative is a joke, and always was. The only reason for ever
using it
is that cooperating was perceived as "simple to implement", and some os
designers
had the mistaken belief that you could expect application programmers to
be "diciplined enough" to yield the cpu often enough. They couldn't be
more wrong.
There are too many bad application programmers around.
Just expect more from your machine than cooperative os'es can give you.
> 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.
>
Now to something completely different:
> 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.
Write patches then. One thing you really should know before posting
here:
Nobody works for you here, so you *can't* request _anything_. It is a
great way of pissing people off. People here code up whatever _they_
want,
not what you want. There is no service.
The correct question is this: "Would it be a good idea for *me* to
fix this, and if so, can someone help me getting started?"
> 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.
This is by design. There is no modules API. If you need a stable API,
code modules for a single kernel revision. You may have some mistaken
idea about what modules is in linux. Not necessarily what modules is
in other os'es. You are expected to recompile all modules with each
new kernel revision, just like compiling the kernel itself.
A module is merely a part of the kernel itself which doesn't have to be
there
all the time.
> 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.
>
Yes, modules can easily bring the kernel down. Error in a module can
crash the kernel just like an error in the kernel can crash the kernel.
This because a module is a part of the kernel, there is no difference
or protection. The _only_ difference is that any module can be
loaded a long time after the kernel is booted, and most modules can be
unloaded
as well.
So modules can be used to save memory. And they simplify distributions
as you make a bootable kernel smaller than the size of a floppy, and
still
provide support for absolutely any hardware by loading modules from
other floppies or the cdrom. And developers can unload a module, fix
the code, recompile it, and load the new module without booting.
And that's it. Modules are _not_ an attempt to be microkernel-ish.
They are not supposed to be in a protected space, as they aren't
different
from the kernel. They are the kernel, just like the memory-resident
code.
If you want something in a protected memory space - write a program.
If you need this to be a driver, write a minimal device driver and a
program, and let the program handle everything that don't need to be
in the driver.
> 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.
A pc speaker driver is a bad hack, and I can't see how you possibly
could
make it a good driver. (by the definitions of good driver used here.
A good driver don't merely do its job, it is also required not to mess
up the
rest of the system by bad delays and/or hacks into how the rest of the
os works.)
The pc speaker is fine for playing one note at a
time - it is extremely shitty hardware if you want to play samples.
A dirt cheap used soundcard or even a resistor network connected to
the parallel port is a good DAC-device compared to the pc speaker.
> It would seem that a microkernel design would fix most of these problems. Two
A microkernel gives you the kind of modules _you_ want. Maybe you
should use
a mickrokernel then - there are several. But note that this comes
at a price. A performance price people here don't want to pay.
> 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.
The amiga don't have memory protection, so any program can crash it
with pointer errors and such. Linux is a memory-protected system,
a user program _can't_ crash the kernel by overwriting memory. You may
not need that - but most linux users want it. Oh, and you complained
that linux modules don't have memory protection?
Another issue - linux runs on many platforms. So something written for
a single machine will often beat it on that machine, if it is
well-written.
>
> 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?
Follow the list. You will notice quite a few things that are postponed
until the 2.5 development begins. Such as further VM improvements,
further
VFS improvements, even better SMP scaling, major rewrites of some device
drivers.
If you want to help, do write drivers for unsupported hardware. That's
a way to become a useful contributor fast. Leave major design issues
till later. Ideas from someone with an informed opinion is fine, but
"I don't know much about linux yet and haven't looked at archives but
I have some ideas for radical changes anyway" don't fly. There are
plenty of reasons for why your design ideas wasn't implemented years
ago, and they are explained in great detail in the message archives.
Helge Hafting
-
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:20 EST