The Holy War: Monolithic vs. MicroKernel

[df]

monolithic.
nt3.5 had lot more protection for drivers than it currently does...

[Tim]

kernel.com.au: The distinction I'm familiar with is that a microkernel has system services split into separate tasks -- threads -- whereas a monolithic kernel services system services in one thread (usually the thread calling the service). There's nothing in that definition to stop threads in a microkernel poking at each others' memory or calling each others' function, and therefore nothing to stop them becoming one big blob.

If each service is in a different address space then the coupling becomes more loose and certain types of coupling are prevented. With a monolithic kernel it's up to the writer of the source code to keep the code structured. As a user I prefer code which works fast to code which is nice inside. (As a programmer I prefer nice code to fast code, so I hope I've found a balance between nice and fast in the middle.)

df: Only for video drivers. Most drivers have always been in the kernel; with NT 4 onwards, video drivers were moved into the kernel too. Frankly I think there are greater risks security and stability risks from drivers which have always been in the kernel (for instance, NIC and network protocol drivers) and video drivers are nothing to worry about compared to those.

xxchrisxx: Those all use monolithic kernels. The only commercial microkernel I know of is QNX.

[Curufir]

kernel.com.au: The distinction I'm familiar with is that a microkernel has system services split into separate tasks -- threads -- whereas a monolithic kernel services system services in one thread (usually the thread calling the service).

I don't like that definition.

I prefer to think in terms of resource management. A monolithic kernel handles pretty much all resource management from within the kernel. In its purest form a microkernel only handles management of IPC within the kernel, the rest is farmed out to privileged processes external to the kernel itself.

Or to put it another way it is a question of policy determination. In a monolithic kernel policy is dictated by the kernel itself and no negotation is required since all policy is known in advance. In a microkernel policy is dictated by processes outside the kernel and the kernel simply acts as negotiator between those processes.

Don't know if I described that very well. It seemed a lot clearer before I read it back .

[BI lazy]

*juggling with mixed pickles in a jar*

@curufir: that's mainly how a microkernel is intnded to work. A service process handles the management of ressources (drivers) and policy. the service process tells the driver what to do.

A special oddity to this is memory management. Since I use paged memory and a process is defined as something which owns a pagedirectory - own adress space f. ex. - in blue illusion, I've been in need of a more sohisticated mechanism to get the pagetables stuffed into place as soon as a process is created. Therefore, the only thing that is created upon process creation - is the page directory. The rest is done by pagefaults. To achieve this, I did a split between management/policy and execution (the pager beast). the pager beast is a slimy little weasel that slips into process adress spaces at need - and fills in the pagetables and loads process data, just when a pagefault occurs. So, I didn't need a complicated structure. Just some messages, some distinction between new process and old process ...
(0xdeadbeef comes in handy here)

What I want to say is this: Be it a monolithic kernel, be it a micro kernel: it's all a question of design and policy. (did somone else say this too? I'm too tired today)

Hm... I think i'll do semaphores directly in the kernel. It just requires two extra system calls, but I think this one would be a nice alternative to the message passing for syncronizing threads.

stay safe

[FlashBurn]

Correct me if I?m wrong, but the opinion of the most here is that microkernels are slow?! But what is with BeOS, as far as I know it is a microkernel and it is damn fast ;D

[Solar]

We're not saying that a fast microkernel is slower than a slow monolithic one.

But by design microkernels have to overcome the disadvantage of having more inter-process communication to handle. More messages, more context switches.

You can overcome these disadvantages. Just as well as you can create a solid, reliable and modular monolithic kernel. Neither is impossible.

[xxchrisxx]

I see that a few of you are on the Microkernel side. What makes you choose this, and go in the opposite direction of most other modern OS's?

P.S. When you all explained the Microkernel design to me, it seemed to be the right idea. So far Microkernel is my choice. My OS is going to heavily modular and aimed at stability.