The MH microkernel

History and motivation

As opposed to other kernels and microkernels – probably –, MH is based on a completely random ideology, picked arbitrarily, in a Cambridge pub, after evidently too many beers.

Unimpressed by the lack of shape in modern software, some day in 2014 I thought that it would be really cool to build a system made of tangible abstractions. A system described in terms of objects that can be very easily understood would be – I decided – very pleasant to play with, and to use as a base for complex systems!

A system built with a single tangible abstraction – I continued – would be even more pleasant and simple!

Abstractions and inspirations

The search for that abstraction wasn't easy. Ruled out exokernels and L4 pretty quickly, I decided to have a look at the classics.

Mach is beautiful, if you don't look at the code. I had my share of fun hacking it and it is definitely made of abstraction that are easy to tinker with, and that have proven themselves definitely capable of building complex systems since 1985. But its abstractions are not clearly linkable to well defined existing objects: every introduction to Mach needs to explain what is a port, and port sets, and port rights, and memory objects.

The beauty of Mach, and what I wanted to take from it, is that it defines its basic abstractions, and a set of principles, and maps every possible activity of a computer into these abstractions. Mach calls you into experimenting with it. That's what I wanted to have.

Another system I wanted to steal from is the UNIX operating system. "Everything is a file", despite being a lie since at least the addition of networking, is an incredibly powerful principle.

The early UNIXes loosely presented to the user a model of what a machine was at the time: a single cpu, interrupts (signals), a disk (filesystem), and a terminal.

World views

The world of a userspace program in Mach is made of ports and memory objects, in UNIX is that of a simplified computer. I liked the latter. A computer is understandable by a programmer.

I decided to move toward a system that presented something familiar, a UNIX process model, in a world where a computer is not made only of internal disks and not many terminals are around. Furthermore, I wanted to achieve an extensibility similar to that of Mach by letting userspace processes export the same abstractions that the kernel uses to export its services. And finally, I wanted a system fun to use and extend.