Here is an image of a conceptual architecture for unix systems (edit - not mine or anyone's in particular - just pulled it from the net). What would you change, add or delete and why?
The first thing that comes to mind for me is that that "assemblers, compilers, linkers" could be revised to read "development platforms, extensible frameworks, compilers, linkers, assemblers", something like that.
Or should "development platforms, extensible frameworks" be a type of application program?
That onion picture doesn't quite work for me. A compiler is necessary to build C programs, but after that, the programs are freestanding. Shells don't exist at any higher level than application programs; they're just executables too. So sometimes the diagram describes the way things are connected; other times, it just describes how they're commonly used.
Agreed. It really is not technically accurate when you think about it. The onion approach for the concept architecture does not work well at all.
The system call interface layer could mislead the uninitiated into believing that system calls exist outside/above the kernel. If that were my "onion", I would delete the system call layer and enlarge the kernel, subdividing it into two layers (perhaps with a bit of shading): 1) drivers, adjacent to the hardware, and 2) system calls adjacent to userland.
EDIT: Put differently, I'd relabel "kernel" as "drivers" and indicate that "kernel = system call interface + drivers".
Regards,
Alister
and with virtualization entering the game, the onion tends to become kind of fractal ...
I would add a thin libc layer between the "system call interface" and the userland executables, instead of the compiler/assembler layer.
Regards,
Alister
1 Like
Yeah -- for that matter, it doesn't mention libraries in general.
There is "system libraries" in the bottom of the middle (assembler, compilers, linker) circle.... (it's at the bottom, so a bit harder to see)
Eyedrops applied. 
Regards,
Alister
Does anyone wish to volunteer to create a draft revised version of "the onion" conceptual unix architecture based on the discussion so far, and upload the new image for more discussion?
I've been working on something actually, but keep rearranging and revising it. I'll post it if/when I come up with something I'm happy with.
I've never seen one of these that I like and probably never will. It used to be that I could agree with one or two inner circles. But now we have virtual systems. The kernel might not be wrapped around real hardware any more.
But about your onion... the assembler is usually known as "as". You have "as" as an application program. Maybe you should move it the "assemblers and compilers" layer.
Hi.
For the topic of how components fit together, I preferred an O'Reilly graphic from Power Tools, rather than the onion for training in *nix -- see Figure 1.1 on page 8 (click Browse Contents button on top of book image) at Unix Power Tools, 3rd Edition-O'Reilly Media or see page 5 of the really long PDF O'reilly Unix Unix Power Tools (5.6 Mb) PDF Ebook Download
(I'm not sure I can post it directly from O'Reilly or from the pdf for legal reasons, there may be other sources, and it's possible that O'Reilly might not mind, but I just don't know.)
It was better for me in the pedagogical sense, because I could start with the User block on the whiteboard, and develop the diagram as the topic unfolded. Not much drawing skill was required, thankfully.
One could then discuss development, libraries, etc. -- very open-ended -- with simple block diagrams. Having the students do the drawing as we talked and answered questions helped them see and internalize the big picture -- which is what we called that section ... cheers, drl
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