Linked by Thom Holwerda on Tue 9th May 2006 21:25 UTC, submitted by luzr
OSNews, Generic OSes Torvalds has indeed chimed in on the micro vs. monolithic kernel debate. Going all 1992, he says: "The whole 'microkernels are simpler' argument is just bull, and it is clearly shown to be bull by the fact that whenever you compare the speed of development of a microkernel and a traditional kernel, the traditional kernel wins. The whole argument that microkernels are somehow 'more secure' or 'more stable' is also total crap. The fact that each individual piece is simple and secure does not make the aggregate either simple or secure. And the argument that you can 'just reload' a failed service and not take the whole system down is equally flawed." My take: While I am not qualified to reply to Linus, there is one thing I want to say: just because it is difficult to program, does not make it the worse design.
Thread beginning with comment 123384
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: My Take!
by Brendan on Thu 11th May 2006 06:40 UTC in reply to "RE[3]: My Take!"
Brendan
Member since:
2005-11-16

Modern device drivers tend to be composed of a "bottom half" and a "top half" (terminology varies) in which the "bottom half" has to operate with low latency, and so does very little work, mostly in the form of state transition and data grabbing. The bottom half queues up work for the top half on input and the top half queues up work for the bottom half on output. Operations on the queues require synchronization.

That would be implemented as a multi-threaded process, with a very high priority thread (the top half) and another thread (the bottom half). This involves process specific locks, not "inter-process" locks.

Also, drivers require memory, especially storage drivers, and need to obtain it from a memory pool, so drivers have to synchronize with each other and the memory pool manager.

Each process's virtual address space is independant. It's like normal applications calling "sbrk()" on *nix - no explicit synchronization needed between the processes.

That's not a function of "micro-kernel", it's a function of separating address spaces used for data pools and using the hardware VM's memory protection. A "microkernel" on a machine without virtual memory isn't going to have that sort of protection, and a "macrokernel" on a machine that has virtual memory can have it. (See the Brevix paper for a discussion of how it was done on PA-RISC.)

Sure, but if a monolithic kernel (rather than a "macrokernel"?) on a machine that has virtual memory can have seperate "access spaces" for device drivers then we're quickly running out of differences between monolithic kernels and micro-kernels.

To be honest I lean towards the original definition of the term "monolithic", which literally means "single piece, like stone". I know the term is used "less literally" when it's used to describe kernels, but at at the rate monolithic kernels are adopting "micro-kernel-ish" attributes we're going to need to start calling things like QNX monolithic soon (examples include dynamically loaded modules, sandboxing (Nooks), support for user level drivers (Vista), etc).

Reply Parent Score: 1

RE[5]: My Take!
by Cloudy on Thu 11th May 2006 08:14 in reply to "RE[4]: My Take!"
Cloudy Member since:
2006-02-15

"Modern device drivers tend to be composed of a "bottom half" and a "top half" (terminology varies) in which the "bottom half" has to operate with low latency, and so does very little work, mostly in the form of state transition and data grabbing. The bottom half queues up work for the top half on input and the top half queues up work for the bottom half on output. Operations on the queues require synchronization."

That would be implemented as a multi-threaded process, with a very high priority thread (the top half) and another thread (the bottom half). This involves process specific locks, not "inter-process" locks.


I was responding to the claim that If there's multiple instances of a device driver (multiple devices of the same type), then each instance of the device driver would only access it's own device, and there'd still be no need for locking in the device driver.

whether the synchronization occurs within a thread, between threads, or between processes is an implementation detail. There is synchronization, to resolve latency issues.

"Also, drivers require memory, especially storage drivers, and need to obtain it from a memory pool, so drivers have to synchronize with each other and the memory pool manager."

Each process's virtual address space is independant. It's like normal applications calling "sbrk()" on *nix - no explicit synchronization needed between the processes.


Storage drivers, especially those that implement things like software raid, or that service the disk cache, even if they are implemented in separate processes, need to have access to a common pool of memory. That definitely requires them to synchronize.

Anyway, you're trying to have it both ways. Either the driver is implemented as threads in a process, or it's implemented in pieces in separate processes, it's not both.

"Microkernel" initially meant a system that had a certain set of attributes, a key one of which was message passing, and another separate address spaces for separate components. So called "hybrid" systems drop both of these, and are indistinguishable from "monolithic" kernels, in the original meaning.

Reply Parent Score: 1

RE[6]: My Take!
by Brendan on Thu 11th May 2006 09:20 in reply to "RE[5]: My Take!"
Brendan Member since:
2005-11-16

I was responding to the claim that If there's multiple instances of a device driver (multiple devices of the same type), then each instance of the device driver would only access it's own device, and there'd still be no need for locking in the device driver.

What I'm trying to say is that if a device driver is implemented as a seperate single-threaded process then it requires no locks at all, and if a device driver is implemented as a multi-threaded process any locks are confined within that process and don't need to be used by other processes.

Storage drivers, especially those that implement things like software raid, or that service the disk cache, even if they are implemented in separate processes, need to have access to a common pool of memory. That definitely requires them to synchronize.

Need?

I guess it does depends on how the OS is designed (rather than what sort of kernel is used, etc). I use asynchronous messaging, where messages can be large (e.g. 4 MB) rather than tiny (e.g. several dwords). For the "tiny messages" case you probably would need shared data, but it's completely inappropriate for distributed OSs so I don't use it.

For me, only one process ever has access to "common pools of memory". For example, the "VFS process" would have a disk cache that only it has access to. If it needs something that isn't in this cache it requests the data from the appropriate file system code. When the VFS receives the data it inserts it into it's disk cache and complete the original request.

Reply Parent Score: 1