Linked by Thom Holwerda on Sun 16th Apr 2006 15:36 UTC
OSNews, Generic OSes Right in between a car crash and Easter, I knew I had to write a Sunday Eve Column. So here I am, digesting vast quantities of chocolate eggs (and I don't even like chocolate), craving for coffee (for me about as special as breathing), with the goal of explaining to you my, well, obsession with microkernels. Why do I like them? Why do I think the microkernel paradigm is superior to the monolithic one? Read on.
Thread beginning with comment 115671
To view parent comment, click here.
To read all comments associated with this story, please click here.
Cloudy
Member since:
2006-02-15

The point is that for monolithic kernels you don't have these options - if anything in kernel space dies you have to assume that everything in kernel space has become unreliable, and rebooting is the only reliable option (if the code to do a kernel panic and reboot hasn't been trashed too).

This is true in most implementations, but it is a feature of the implementation rather than a necessity of the system. It is, given reasonable VM design, possible to make the user/supervisor transition distinct from the addressability distinction.

You can have a 'monolithic' kernel in the user/supervisor sense -- meaning that the whole thing is compiled as a unit and all runs in supervisor mode -- without having to have one in the memory addressability sense -- meaning that various subsystems can only access what they're allowed access to.

Reply Parent Score: 2

Brendan Member since:
2005-11-16

This is true in most implementations, but it is a feature of the implementation rather than a necessity of the system. It is, given reasonable VM design, possible to make the user/supervisor transition distinct from the addressability distinction.

Unfortunately, all VM implementations are restricted by what the hardware provides. For (32 bit) 80x86 this means paging and segmentation. Therefore, to seperate access from addressability you'd either need to modify the permission bits in the paging structures during each transition (very time consuming) or use segmentation.

While segmentation could help, it isn't a complete solution - it can provide a distinction between 4 privilege levels, but code at higher privilege levels can trash anything at lower privilege levels (e.g. drivers could trash user space and each other, but not the kernel itself). Of course for portability (even to 64 bit 80x86) you can't rely on segmentation anyway.

I guess it would be possible to design hardware to overcome this problem, but IMHO it'd make more sense to make context switching faster. For e.g. have "CR3 tagged" TLB entries so that address space switches aren't so expensive, which would benefit all kernels to varying degrees and could be added to 80x86 without requiring changes to any existing software.

Reply Parent Score: 1