Mach Microkernel

The Mach MicroKernel started as a project in OperatingSystemsDesign at CarnegieMellonUniversity.

The MicroKernel (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 MachMicrokernel 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 MicroKernel at all.

How would a system take advantage of the MicroKernel? I.e., what exactly are MacOsx users missing?

Operating Systems running on top of Mach:

NextStep operating system (which did use the features of the microkernel a bit better than the standard BSD sever)
MacOsx, being highly derivative of NextStep.
MkLinux
The GnuHurd
TruUnixSixtyFour? nee DigitalUnix? nee DecOsfOne?
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 MachMicrokernel was not involved. -- DavidPlumpton. 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? -KristofferLawson

(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 MicroKernel? I.e., what exactly are MacOsx 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, QnxMicrokernel?) 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.

--SamuelFalvo?

ObjectCapabilityOperatingSystem CategoryOperatingSystem