RK0

“In 1972 I wrote a chapter on Resource Protection for Operating Systems Principles. (…) I pointed out that type checking in compilers and resource protection on operating systems are solutions for the same problem: to verify automatically that programs only perform meaningful operations on data structures.”

P.B. Hansen, The Architecture of Concurrent Programs, 1977.

It is interesting that the operating systems born in the era of application-specific, hardware-dependent systems programming were often shaped by formal reasoning that almost resembled an algebra.

RK0’s not-so-layered architecture traces back to Hansen’s RC4000, the first operating system kernel in a recognisable sense. And it was a microkernel in the strict sense long before it was a term.

The lessons of the first multitasking operating systems probably still have more to teach real-time systems than much of today’s habit of importing general-purpose systems gospel into domain-dependent real-time software.

A kernel built for real-time work should not let execution progress emerge from poorly defined reasons. If a task blocks, wakes, becomes READY, inherits priority, or resumes execution, the cause should be explicit enough to analyse.

That is why RK0 adopts a scheduler-centred model: no mechanism that changes a task state bypasses the scheduler.

There is a useful historical parallel here with Dijkstra’s semaphore idea and THE multiprogramming system.

In the classical semaphore model, a task advances through disciplined operations such as P and V, mediated by an internal semaphore state. The primitive determines whether execution continues or blocks.

RK0 tries to preserve that same discipline, without collapsing all coordination into one general primitive.

It makes explicit not only that progress is controlled, but why it is allowed.

Not all progress is the same

Many kernels offer a set of mechanisms that are treated as roughly interchangeable. And the distinctions are mostly a matter of API flavour.

Different causes of execution progress carry different consequences. The choice in RK0 was to preserve those distinctions in the name of analysability.

A real-time kernel should make execution policy visible. This statement has been formulated on several ways on RK0 documentation.

The consequences of this design are reflected in the services the kernel provides.