Basically, it's a big blob! But some structure can be introduced:
Also, extensions can be loaded to the OS after booting: shared libraries (UNIX) or dynamic link libraries (Windows).
An early layered system was THE. Its layers were:
| Layer | Function |
|---|---|
| 5 | The operator |
| 4 | User programs |
| 3 | Input/output management |
| 2 | Operator-process communication |
| 1 | Memory and drum management |
| 0 | Processor allocation and multiprogramming |
Understand here that "users" were not "on" the system: they were submitting batch jobs. The "operator" was a person who could control... i.e., delete, reschedule, halt, etc. these batch jobs. That is why the operator layer is above the user layer.
The basic idea is that processes running in ring n + 1 cannot alter processes running in ring n, but the reverse is false.
Why microkernels?
Bugs per 100 lines of code: between 2 and 10. That means a
big kernel is likely to contain between 10,000 and 50,000
bugs!
The authors claim that cars, TV sets, and stereos do not
have reset buttons. Hmmm...
Nevertheless, microkernels do offer a stability
advantage. OS X is based on the Mach microkernel. Many
real-time, industrial, avionics and military systems use
microkernels.
Minix: The kernel is 12,000 lines of C and 1400 of
assembler.
Compare: The
core of the Linux scheduler
is 2200 lines of C. There are
27 other source code
files comprising the scheduler. And
the Linux kernel
contains 13 other modules like that, plus 80 or 90 source
code files in the main directory.
And some of the source is
a little difficult to read.
In the above figure, contemplate the effect of a buggy printer driver in each style of OS.
Web servers are a great example. Apple voice-recognition, Dropbox, Google Docs are others.
Used extensively in web hosting.
See
hypervisor ad
.
The same Java program can run on many different
systems.
But not only that: there are many languages that can
run on the JVM:
The exokernel just keeps virtual machines out of each other's hair.