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.

Understand the Real-Time Model and Service Map.

The Requirements map test cases to functional requirement IDs.

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

---

Programming with RK0

Shared-state vs Message-Passing paradigms: your choice

RK0 supports both paradigms. You can stick to one or use both, as demonstrated on the application example.

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, we chose to call a Task:
  • User Tasks and System Tasks have the same privilege while running on separate stack pointers.
  • Rationale for both decisions is in the Docbook.

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

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.

---

---

Answers

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)