pardo@june.cs.washington.edu (David Keppel) (04/24/91)
There are at least three kinds of OS kernels: monolithic, modular, and kernelized. I would like comments (e-mail, I'll summarize) on what's missing, wrong, or "right but not the only way to see it" with the following definitions: * Monolithic Traditional: everything runs in one address space, the only official interface to the kernel is e.g., the published set of system calls. * Modular The official kernel interface specification may also include internal components along module boundaries. These internal components are not visible to user-level processes, they are for e.g., kernel extesibility. (The word `modular' is a misnomer and I'll gratefully accept alternatives That is, a monolithic kernel may be built using good, modular, structured programming techniques without exporting the particular interfaces. A ``modular'' kernel exports those interfaces and they don't change between releases of the OS.) * Kernelized (or micro-kernel) An OS that is both modular and has modules broken in to multiple address spaces. Comments? ;-D on ( Pay no kernel tax on'a me! ) Pardo
lowry@watson.ibm.com (Andy Lowry) (04/26/91)
In article <14956@darkstar.ucsc.edu>, pardo@june.cs.washington.edu (David Keppel) writes: |> There are at least three kinds of OS kernels: monolithic, modular, |> and kernelized. I would like comments (e-mail, I'll summarize) on |> what's missing, wrong, or "right but not the only way to see it" |> with the following definitions: ... |> * Kernelized (or micro-kernel) |> |> An OS that is both modular and has modules broken in to |> multiple address spaces. I think I'd rather say that kernelized means that the OS is modular and is built in such a way that modules *can* run in different address spaces. Such an OS might run in several address spaces, but with the right technology, the modules can also be squeezed transparently into a single address space to gain efficiency. I would not say that the resulting OS is not kernelized. In order to pack modules *transparently* into a single address space, you need technology that will ensure that they cannot interact in any new ways, e.g. because one module has an out-of-range array reference that ends up altering another module's private data. An example of technology that can achieve this is the Hermes distributed programming language. Hermes is a secure language, meaning that it is impossible for one Hermes process to have any unanticipated effect on another Hermes process, even if they are run in the same address space. The language has been carefully designed so that these guarantees can be made almost entirely at compile time. The result is extremely light-weight processes with heavyweight process boundaries. One of the primary gains from this is the ability to write programs with very clean, well-defined, and inviolable boundaries and still produce extremely efficient implementations. If you'd like information on Hermes, there's a book just published by Prentice-Hall called "Hermes: A Language for Distributed Computing", by Strom, etc. We also have papers and an experimental prototype available for several Unix platforms. Send mail to hermes@watson.ibm.com if you're interested. -- Andy Lowry, lowry@ibm.com, (914) 784-7925 IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY 10598