Home

RK0: The Real-Time Kernel '0'

"Every Universe of Discourse has its logical structure." (Langer, 1929)

“Real-time” has become a catch-all term, often used to describe online interactive or simply fast systems. However, this isn’t a correct definition. With so many loose terms, at least this one is solid:

A system is real-time if any of its responses must be completed within a guaranteed time frame, regardless of execution time, considering interference from other tasks, if it is concurrent.

So, if concurrency is already difficult, when you need to bind it to real-time responsiveness, you will eventually start asking yourself whether we have the right tools for the job. The crude answer is: we don't. Response time emerges from implementation. To increase our chances of getting it right, we need a simple mental model.

---

The Docbook provides design internals, rationale for design choices, some theory, and rich usage examples.

---

Getting Acquainted

1. The Execution model:

The Execution Image is a single-process. Roughly speaking, we enable concurrency within a single process by composing a thread of execution with a unique portion of the running stack. This composition gives us a schedulable unit, which we chose to call a Task. System Tasks and User Tasks have different stack pointers, but user tasks run privileged. The rationale for this choice is in the Docbook; to summarise, it is a choice of non-compromising analysability and responsiveness for the given target systems. The rationale behind this choice is detailed in the Docbook. Essentially, it’s about maintaining analysability and responsiveness given the target systems: constrained firms and hard real-time application-specific computers. (A version that splits the user space from the kernel space is under development.

2. The Design Ethos and the Real-Time Model

3. Memory Model: Memory is mapped to the physical memory

We are talking about CPUs in the range of 8-256 KiB of RAM. Application-specific needs for dynamic allocation and deallocation, as well as some kernel mechanisms, make use of an allocator that suits real-time demands: fixed-size blocks, word-aligned, O(1).

4. Programming with RK0:

Shared-state and message-passing are supported. You can stick to one or use both, as demonstrated on the application example.

---

Where RK0 fits and where it doesn't

• RK0 is a suitable system whose quality of service degrades quickly when not meeting time constraints. Tasks can't be unaware of each other and are actually cooperating concurrent units. The solution is domain-dependent. The hardware is domain-dependent. The deployed application was tested and is trusted. This is the typical closed model that most real-time critical applications fit.

• It doesn't target any solution that until recently was handled by MMU-equipped, moderately powerful devices, running tailored full-fledged OSes (historically BSDs, until Linuxes prevailed); anything that faces it on the web, exposing to a high attack surface.

---

Functional Requirements mapping to test cases

---

Q&A

Q: Why is there no release yet?

A: A release is serious stuff. v1.0.0 will come when I can push:

• a good Trace mechanism (it is ongoing)

• can provide meaningful and honest system characterisation (it is ongoing)

• the test harness in a way it works for any potential contributors (it works on my computer)