Messages in this thread |  | | Date | Mon, 23 Oct 2000 09:58:03 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: 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.
Cheers, 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |