[lkml]   [2000]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Topic for discussion: OS Design
"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.

I think everyone who first writes here and hasn´t read the archives asks
This is a technical mailinglist ... If you have technical comments which
are welcome, you are welcome otherwise go to play.

> 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.

Yeah 16 year old calling himself a programmer ... Ever heard about
programming theory OS design theory?? Ok alan (-> Alan Cox ...) says
that there is a HUGE difference between theory and practise...

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

and beating phrases

> 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.

Yes, and pre-emptive _is_ better because one cannot rely on the user
being sensitive ...
especially script kiddies like 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.

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

Is it?? its only designed to make it possible to link parts of the
kernel during runtime ... makes debugging frivers easier ...

> 1. Many things are inaccessible to the modules: There are relatively few
> kernel modifications that can be compiled without patching the pristine
> sources.
Ehhm as modules run in kernel nearly everything is accessible for em ...
as long as they do it the right way. When things arent accessible for
modules it is because its well thought of...

> 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.

Nope the API is developed with the kernel ... And its really easy to
design a device driver ... Try it ... look at the joystick driver... for
a start ...

> 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.

Wepp- run em all in seperate memspaces and do context switches all the
time which is one of the most time consuming tasks on a cpu ... (saving
and restoring a whole register set ...)

> 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.

Amiga design is *old* ... Windows is relatively old QNX is hacked to fit
onto a floppy and it is a RTOS for you who doesnt know: Real Time
Operating System, Real time means that the OS has to respond to requests
in a certain time which is well defined ( could also be 1 second, but
the OS has to guarantee that it will handle any request in the worst
case in 1 second (latency) which is highly unrealistic (1 sec) There are
linux low-latency patches which make linux more responsible (probably
what you call "speed")

Linux does fit on a floppy too (there are enough tars you can
> 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 -
> - 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.
Wow, ure the king here aren´t you??

> - See the mail headers for GPG/advertising/homepage information.
^^^^^^^^^^^^^^^^^^^^^ I dont care about such crap, and I´m sure
everybody else here doesnt...
> ------------------------------------------------------------------------
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:41    [W:0.165 / U:2.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site