[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.156 / U:5.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site