[lkml]   [2000]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Topic for discussion: OS Design
    On Sun, 22 Oct 2000, Dwayne C . Litzenberger wrote:

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

    From time-to-time, the linux-kernel list gets inquiries that
    may generally be considered to be coming from a troll. However,
    some of these inquiries seem to be somewhat valid and seem
    to have been generated by some well advertised misinformation.

    In particular, often certain buzz-words are used to "prove",
    "demonstrate", or simply "show" that one particular implementation
    detail is better than another.

    I'm going to address just one detail of this misinformation,
    "kernel modules".

    o Once installed, a kernel module is every bit as "efficient"
    as some driver linked into the kernel at build-time. Of course
    the code necessary to install and remove a kernel module may not
    very efficient because it was designed to be straight-forward and
    reliable, not necessarily efficient. After all, a module is typically
    installed in the kernel once, early in the boot process. Nothing,
    absolutely nothing is, as you say, inaccessible to the module unless
    it is inaccessible to other parts of the kernel (like a DECnet address
    in Redmond).

    o A kernel module is a piece of kernel code. It executes
    as part of the kernel and, therefore, can do anything it wants
    to do including destroying anything. A kernel module is not a
    piece of user code that gets a chance to run with some advantage
    within the kernel. If a kernel module was designed for this
    purpose, the kernel module code is being misused. A "microkernel"
    provides no protection for bad modules. This buzz-word is irrelevant.

    o Because of the excellent design of the kernel module interface,
    practically any amateur 'C' coder can write a kernel module. If that
    coder has access to the root account, the module can be installed.
    The result often proves that it takes more than the knowledge of a
    'C' compiler to produce something of value that executes within kernel
    space. The fact that it is possible to write code that destroys the
    kernel is irrelevant.

    If the proper kernel interface code is used, like copy_to_user(),
    copy_from_user(), etc., within the module, it is impossible for a
    user to hurt the kernel from the user's API. FYI "highly volatile"
    make no sense. In the context of programming an object is either
    volatile or not. It cannot be "highly volatile".

    o The ability to install and remove modules from a running kernel
    is one of the most significant accomplishments of Linux. Anybody who
    has written drivers for other operating systems can substantiate the
    awful development cycle. Typically, you write the driver according
    to a template provided by the vendor. You finally get it to compile.
    Then you run some obscure vendor-supplied program that 'links' it
    with the operating system. Then you reboot.

    You do this over-and-over again until you have discovered all the
    errors in the vendor's documentation. Eventually, you get to test
    your driver code. It doesn't work.

    Then you get more incorrect documentation and discover that the
    kernel interface has changed. You repeat this whole episode until
    you finally get to 'talk' to the hardware that your driver is
    supposed to control. This is only the beginning.

    With Linux, you just write the code. You put in a few debugging
    statements here and there. You make sure you don't do something
    dumb like write to some address you don't own, you compile it,
    then you insert it using `insmod`. If it doesn't work, you use
    `rmmod` to remove it. If the documentation is wrong or hasn't
    been updated, you just *look* at the source-code, observing how
    some other working module did it.

    o What used to take a month to get working in SunOS, will
    take a few hours on Linux. Linux has continually improved the
    resources available to the modules. In the beginning there was
    a kernel memory allocator. Now we have common resource allocation
    code for I/O addresses like PCI, common interrupt handlers, common
    sleep and wake-up routines, etc. Basically, the best ideas of
    all the driver contributors have been adapted into a kernel-driver
    interface so that every compliant module gets to share the best
    code available.

    Dick Johnson

    Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).

    "Memory is like gasoline. You use it up when you are running. Of
    course you get it all back when you reboot..."; Actual explanation
    obtained from the Micro$oft help desk.

    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.028 / U:0.624 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site