Quote of the week [LWN.net]

Whilst Red Hat's medical coverage fully covers "mental health" issues, I'd really rather not proceed down this avenue. We can't support *one* kernel properly. On what planet does it make sense to throw more variants in the mix ?

-- Dave Jones

(Log in to post comments)

Quote of the week

Posted Jan 5, 2007 3:01 UTC (Fri) by jd (guest, #26381) [Link]

The quote was in reference to Fedora providing many different types of kernel (Xen, Real-time, etc), to judge from the originating article.

My answer to that is fairly simple. In a correctly-designed system, any given layer should be oblivious to the details of the layers above or below. It needs to know how to communicate between layers efficiently, but beyond that, the details are of no consequence.

In a hypervisor system, the kernel exposes details to the hypervisor and gets the hardware details from the hypervisor.
In a virtual machine, no details are exposed, but hardware details are still passed up.
In a real-time system, you'll need some way of handling externally-generated events and parallelizing non-interruptable code so that time-slices can be rigidly enforced.
In a fully "trusted" system (it'll happen eventually), you'll want external policy control over things like physical memory.

All these sound to me like cases where you can have all the necessary hooks built into a totally generic "one-size-fits-maul" kernel. If a hook wants to be disabled, you have plenty of options. The slow-but-safe way would be to have some modules that are just stubs that the hooks can use instead of whatever external thing they'd look for. The faster, more dangerous, insane, and therefore the way with the greatest geek quotient, is to mark these hooks and no-op them out at runtime if they're not being used. In a way, this is better because then you can't accidentally compromise the configuration later on by loading/unloading one of the stub modules.