Hi everyone,
I’ve been working on a small experimental operating system kernel called Rk-C, written mainly in Nim, targeting RISC-V 64-bit on QEMU + OpenSBI.
Repository: https://github.com/shizuku198411/Rk-C
The project started as a rewrite of my previous C-based kernel. At this point it has grown into a small microkernel-style OS with user-space services, a shell, a custom executable format, basic filesystem support, process management, networking experiments, and some security-oriented mechanisms.
Some of the current features include:
- RISC-V 64-bit kernel running in S-mode.
- User-mode applications.
- Preemptive scheduling using timer interrupts.
- User-space services.
- A custom executable format called RKX.
- Capability metadata in RKX, with kernel-side capability validation.
- IPC-based service communication.
- Basic user/root support, login flow, and file permissions.
- Experimental networking, including ARP, IPv4, ICMP, UDP, DNS, TCP, HTTP, and early TLS work.
Why Nim?
One of the most interesting parts of this project has been using Nim for kernel development.
I originally wrote the kernel in C, but Nim has been a very comfortable middle ground for this kind of work. It still allows low-level control such as pointer operations, MMIO access, custom ABI boundaries, packed structs, and freestanding builds. At the same time, it provides a much more modern programming experience than C.
Compared with C, Nim makes it easier to structure the code into modules, define clear types, and write readable user-space tools and services. Compared with Rust, Nim feels lighter for this kind of small experimental kernel: less ceremony, easier freestanding experimentation, and more direct control when I need it.
Another practical reason is AI-assisted coding. Nim’s syntax is compact and readable, and the language is expressive without being too verbose. That makes it easier to iterate with AI tools: reviewing code, refactoring modules, generating repetitive boilerplate, and exploring implementation ideas all feel smoother than they did in my C version.
In short, Nim lets me write low-level kernel code and higher-level user-space services in the same language, without the project feeling split between “kernel C” and “application language”.
Why build a kernel now?
The motivation is partly educational, but also architectural.
Modern general-purpose kernels have to support a huge range of hardware, filesystems, network protocols, compatibility layers, drivers, and optional features. That flexibility is extremely valuable, but it also increases complexity and attack surface.
My goal with Rk-C is not to replace Linux or claim that this design is better. Linux solves a much larger and harder problem. Instead, I wanted to explore a smaller kernel that only implements the features I personally want to use and understand.
The idea is:
- keep the kernel small,
- move privileged functionality into user-space services,
- make executable metadata explicit through RKX,
- use capabilities to limit privileged operations,
- and avoid carrying features that are unnecessary for my own use case.
For example, Rk-C’s RKX executable format includes metadata such as requested capabilities and stack size. However, the kernel does not trust this metadata directly. It grants capabilities only according to a trusted policy for immutable core applications under /bin, and IPC packets are stamped by the kernel with the sender’s effective capabilities. This helps user-space services avoid confused-deputy style mistakes.
This is still an experimental hobby OS, but the project has reached a point where the core pieces are starting to fit together. Nim has been a surprisingly good fit for building both the kernel and the surrounding userland.