It's not anyone's onion in particular. I just pulled it off the Internet to use to kick off this discussion; so there in nothing personal in the image at all

I think "kernel" is a way to broad category. When you examine what a kernel does there are two different groups of services a kernel has to offer:

A) Drivers These are programs which interface with a piece of hardware and create a generic interface with which other programs can work - usually a device file. If there is any one distinguishing concept of Unix and all Unixoid systems that is "everything is a file". Unix uses "files" (loosely defined, anything with an entry in the filesystem) for about everything: inter-process communication (semaphores, pipes, FIFOs), device interaction, even networking! It fits that the "generic interface" a driver presents to the rest of the OS is usually a device file which can be written and/or read.

Drivers are usually processes in their own right but run with kernel privileges. It is a matter of definition if you see them as part of the kernel or as add-ons to it.

B) Service threads These are all sorts of services a kernel offers to keep the system going: (process) accounting, scheduling, resource management, etc.. Nano- (Micro-)kernel advocates (like Andrew Tanenbaum) argue that only these make for the "kernel" at all and that even some of these could be removed from the "core kernel" to make drivers.

As we all know Nanokernels didn't win out because even the last kernel to be developed - Linux - was a monolithic kernel with the drivers included, much to the chagrin of the Microkernel-advocates. This doesn't mean that monolithics are better at all, just that nobody every tried the other approach in a productive environment.


So my personal "onion image" would be:

hardware
drivers
(other) kernel threads
applications

Even more so because "compilers" (or linkers) are ordinary programs at all. They are in no way more special than "sed", "awk" or any similar text filter, because in fact they are filter programs too: the are fed an input file (the source, the object deck, ...) and produce an output file (the object deck, the executable, the archive, ...) from it by following some rules. Any programming language can be interpreted as command within these rules to produce a certain output (the relocatable or executable code) just like a sed script will produce a defined output from an input.

bakunin