The Mach Micro Kernel started as a project in Operating Systems Design at Carnegie Mellon University.
The Micro Kernel (which isn't so micro by some standards) handles task scheduling, virtual memory abstraction, and inter-process communication and leaves the rest to server processes.
The original Mach Microkernel was used to run the BSD kernel as a server task that provided UNIX system call semantics. Interestingly enough, I don't think this configuration ever took advantage of the Micro Kernel at all.
How would a system take advantage of the Micro Kernel? I.e., what exactly are Mac Osx users missing?
Operating Systems running on top of Mach:
Next Step operating system (which did use the features of the microkernel a bit better than the standard BSD sever)
The Gnu Hurd
RISCOS from the former British computer company Acorn was based on the Mach-Kernel, at least initially. Are you sure? Could you provide any additional evidence for or information on this? RISC OS was based on an OS called Arthur; the Mach Microkernel was not involved. -- David Plumpton. Arthur was RISC OS 1. It has a simple kernel (with no multitasking at all - the window manager handles co-operative multutasking [CMT]) with loadable modules. RISC OS Gold was an attempt to port the RISC OS GUI on to Mach, but it failed horribly. --Rob Kendrick.
I've always wondered how possible it might be to simultaneously run mkLinux and OSX on top of the same Mach kernel as separate services. I never found out anything certain about this. Anyone know? -Kristoffer Lawson
(which isn't so micro by some standards) -- why is it not so micro anymore? I've always heard that it was bloated for a microkernel concept, but I've never seen anything tangible to back the claims.
How would a system take advantage of the Micro Kernel? I.e., what exactly are Mac Osx users missing? -- This depends on how far you want to go.
At a coarse level, you can have microkernel processes on the same scale as Unix processes. In this case, device drivers are maintained in user-level processes that can be launched from system start-up or from the shell with equal facility. Because they're user-level, a process that dies (say, due to a privilege violation) won't bring the whole machine down (like Linux modules can). A process, much like inetd, can be written to watch for driver interaction, and dynamically launch drivers on an as-needed basis. That same process can also watch for premature failures of the driver processes, and relaunch them silently as required. Additionally, you're free to run multiple instances of a driver as required. For example, I can conceive of a system whereby a ramdisk process can provide up to 1GB of RAM space for storage. If you need more, you can run multiple ram disk processes, and use another driver process to bind them together into a single virtual volume. More practically, the same concept can be applied to physical disks, where RAID configurations become as simple as editing a shell script.
At a finer grain, microkernel processes behave with semantics that are compatible with actors in object oriented programming. Therefore, microkernels may provide a better substrate for parallel programming than traditional, monolithic kernels. Since many microkernels provide such a close mapping to Erlang processes, I can easily conceive an operating system designed on top of a microkernel where Erlang is the language of choice, allowing it to better exploit the characteristics of the underlying kernel. Indeed, some environments (IIRC, Qnx Microkernel) have IDL compilers that allows a programmer to code up a daemon process of some kind, and make an RPC client library that talks to it. I suspect that most tools are aware of objects.
See original on c2.com 