OSNews

you could implement message based IPC in a macrokernel too ;-)


preface: i prefer the word "macrokernel" because "monolithic" is really the opposite of "structured", as in a system that enforces logical data / function separation between components, and defines boundaries and communication interfaces for them, be they in the same address space or not
actually the microkernel / macrokernel difference depends on the amount of abstractions the kernel supports via its facilities, and is orthogonal to the monolithic / structured one... but anyway
so, the word "monolithic" or "macrokernel" says something about the way a kernel appears when it has been loaded into memory (i.e. what its binary image contain, from a functional point of view - i.e. it may contain device support code - drivers - it may contain VFS node handling code - filesystems - etc)
if one doesnt take the above digression into account, reading "monolithic" may also denote the way the kernel has been organized, code- and structure wise (that is, implemented with global data structures instead of per -subsystem private ones and access APIs )

but it says nothing about the implementation details of those data structures, and the algorithmic efficiency of code that manupilates them
in practice, one can have a kernel with an internal FS layer and drivers performing, or appearing to perform (that is, depending on the use case and the evaluation metric) worse than a system in which they're external - for some applications global throughput is far more important than latency, for others the converse is true

the problem with latency mainly lies in the cost of resource sharing across processes and now threads
on unix and operating systems derived and inspired from unix, the kernel completely virtualizes the underlying system, and then *is* the system, for all intents and purposes of applications, that can only access the HW via kernel calls
thus the kernel itself is a shared resource, on older kernels this translated into a global mutual exclusion lock, that ensured only one process at a time could be running inside the kernel (meaning, could be waiting on an impending syscall while the kernel executes its part)
this ensured the rest of the kernel code could be lean for the sake of (relative) simplicity, but it also made it not very scaleable
on the other hand, a similar mutual exclusion was introduced by the "hardware layer" of the kernel - when executing some privileged HW operation on a bus or device, HW interrupts were disabled to be reenabled when the operation is completed - this effectively means the systems does not react to user input during that timeframe, since mouse or keyboards events are ignored

what time brought to linux and bsd, was incremental algorithmic updates that pushed locking "down" to individual data structures, making resource contention more granular and increasing scalability at the cost of some added complexity - and, with preemption points, a reduction (yet no complete elimination) of the inactive interrupt window - which yielded higher than before responsiveness and lower *innterrupt* latency (which, it maust be noted, is a separae thing from syscall latency - the time taken by system calls to execute vary greatly across types of calls and with the size of the working sets - thus a worst case value, is usually accounted)

OTOH, other systems developed from scratch have been able to tackle the above problems earlier and more effectively by taking a different design right from the start
many if not all modern microkernels have a couple things in common - one is a fast, usually message based IPC, necessary to achieve adequate throughput while retaining user space servers
another is their claiming to be "fully preemptable" (a new operation may be submitted to the kernel at any time, and the kernel is nearly always ready on interrupts - so the nominal latency becomes the latency of an interrupt serve)
since there are always some lowest level pivileged operations that cannot be preempted, the kernel cannot really be preempted at *any* time, but since these are usually extremely short (orders of magnitude shorter than the normal kernel code path), atomic operations, they might become the actual granularity unit without imposing noticeable overhead

the third is one that partly derives from the former: if you have userland services and a message based IPC system, chance is you'll implement a flexible and so-not-old-unix transaction dispatch mechanism

one interesting side effect is that, if versatile enough, the dispatch mechanism may go as far as to support both user and in kernel servers
then one may build primary services back into the kernel for performance reasons
but because of that dispatch mechanism and because of what is "at heart", it probably won't be a monolithic kernel, rather a structured extended kernel based on a microkernel

you'll have effectively reinvented NT ^_^

Edited 2008-11-12 16:57 UTC