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:

(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.


ObjectCapabilityOperatingSystem CategoryOperatingSystem

View edit of August 31, 2007 or FindPage with title or text search