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 115540
To read all comments associated with this story, please click here.
Why should there be kernels anyway?
by axilmar on Mon 17th Apr 2006 13:56 UTC
axilmar
Member since:
2006-03-20

I think that the concept of 'kernel' is a mistake and it exists only because CPUs are not sophisticated enough to provide proper isolation between software components. The discussion between monolithic kernels/modular kernels/microkernels would not take place if CPUs allowed us to provide only the necessary connections between components.

The reason microkernels exist is because it makes it easier to construct an O/S from components that are physically isolated and can not affect each other. But the physical barriers between processes make microkernels not as fast as 'monolithic' kernels.

I think the solution lies in between: CPUs should provide ways of linking components together without allowing undesirable interactions. For example, a graphics driver component should only be able to access the video card and the application's memory and not all the hardware and memory; a hard disk I/O component should only be able to access the hardware I/O subsystem and app's memory buffers and not anything else etc.

I think the above could be achieved with a solution called 'memory map'. Just like a process has a page map, a software component should also have a memory map, i.e. a range of addresses that it is allowed to access. Inter-component communication shall be possible by mapping one part of a component to another component's memory map. By calling a routine of another component, the current memory map would be replaced with the memory map of the current component; upon return, the previous memory map would be restored. The advantage of this solution would be tremendous flexibility in componentization of an O/S:

1) no performance costs like in a microkernel.
2) no safety/security problems like in a non-microkernel.

Memory maps would make traditional kernels reduntant: all that would be needed is a small program that would coordinate memory maps. The rest of the functionality would be placed in components, the memory maps of which are built by the small program mentioned above.

Reply Score: 1

Brendan Member since:
2005-11-16

I think the above could be achieved with a solution called 'memory map'. Just like a process has a page map, a software component should also have a memory map, i.e. a range of addresses that it is allowed to access.

Accessing RAM is slow, but accessing several levels of the paging structures and severel levels of "memory map" structures and the final physical RAM location (every time the CPU accesses RAM) would be unbearable. That's why CPUs cache the paging structures (TLB), and that's why they'd need to cache the "memory map structures". If you're going to change the "memory map" structures every time the CPU changes between software components then you'll lose the benefits of this caching and end up with "memory map structure cache" misses.

You might aswell just change the paging structures instead (which is what micro-kernels do)...

Reply Parent Score: 1

Cloudy Member since:
2006-02-15

The trick is to use systems on which the transition between protection domains is assisted by the VM hardware rather than hindered. The PA-RISC VM model, for example, makes transitions between memory protection domains very fast, nearly as fast as procedure calls that don't transition.

This is what hardware designers and OS designers keep missing. The VM system should make accessability and addressability of memory distinct so as implementation of protection domains in this way is cheap.

We at HP tried to convince Intel to do this in Itanium, but I didn't stick around long enough to see if it made it.

Reply Parent Score: 2