lkml.org 
[lkml]   [2000]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectTopic 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]
    \
     
     \ /
      Last update: 2005-03-22 12:41    [W:0.027 / U:29.480 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site