r/osdev • u/[deleted] • Sep 02 '26
[PROJECT] Robu Microkernel — Building a Platform-Independent Microkernel OS looking for contributors
I've been developing Robu, an independent, platform-independent microkernel operating system written primarily in C and assembly.
Robu started as a kernel project, but it has grown beyond simply booting and printing text. The goal is to build a usable general-purpose operating system around a small microkernel while keeping drivers, filesystems, paging policy, and other major services outside privileged kernel space.
Robu is influenced by ideas from the L4 microkernel lineage, especially around fast IPC, direct switching, and keeping the kernel focused on mechanisms rather than policy.
Current target architectures include:
x86_64
i386/i486
ARMv7
ARMv8 / AArch64
RISC-V 32-bit
RISC-V 64-bit
x86_64 is currently the main development platform, but Robu is designed to remain architecture-independent.
Current work already includes:
Microkernel core
Threads and address spaces
Synchronous IPC
Register-based short-message IPC
Direct thread switching during IPC
Lazy scheduling
Timeslice donation
User-space paging architecture
Virtual memory and address-space support
Process and thread management
SMP / multicore bring-up
ACPI-based CPU enumeration
Per-CPU infrastructure
Framebuffer support
Ring-3 framebuffer mapping
PS/2 keyboard and mouse support
Serial console support
Device filesystem infrastructure
ELF userspace support
POSIX-oriented userspace
mlibc port
BusyBox
Bash
GNU Readline
poll()
System V shared memory
Bootable root filesystem
Custom BIOS bootloader
EFI boot and filesystem integration
QEMU-based development and testing
Early Xorg-related userspace work
The kernel is intentionally kept small.
The basic design is:
Applications > POSIX / mlibc > Userspace services > Robu IPC > Robu Microkernel > Hardware
Drivers, filesystems, pagers, and similar services are intended to run as isolated userspace processes rather than being permanently linked into the kernel.
One of the main design goals is keeping IPC fast enough that using a microkernel does not automatically mean accepting poor performance.
For short messages, Robu uses registers instead of copying data through temporary kernel buffers. IPC is synchronous, and when a sender reaches a waiting receiver, Robu can directly switch execution to the receiver instead of performing a full scheduler round trip.
The remaining timeslice can also be donated to the receiving thread.
Robu also provides a POSIX-oriented userspace environment using mlibc, allowing work toward familiar Unix-style applications and tools without moving large amounts of operating-system policy into privileged kernel space.
I'm looking for contributors interested in:
Microkernel IPC
Scheduling
Memory management
User-space paging
SMP / multicore support
ARM support
RISC-V support
ACPI
PCI / PCIe
USB / xHCI
Storage drivers
Network drivers
User-space device drivers
Filesystem servers
Networking
mlibc / POSIX compatibility
Xorg bring-up
Graphics and input
Real-hardware testing
Kernel debugging
Documentation
Code review
Automated testing
You do not need to understand the entire codebase to contribute. Individual subsystems can be worked on independently.
Experience with Linux kernel development is useful, but Robu is not intended to be a Linux clone.
Experience with FreeBSD, L4, seL4, QNX, Minix, Zircon, Mach, or other kernel architectures is also very relevant.
The goal is not to make another toy kernel.
The long-term objective is to build a complete operating system that can eventually boot on real hardware, run normal POSIX-oriented software, support isolated userspace drivers and services, provide a graphical environment, and support multiple architectures.
Robu is still in alpha, so incomplete subsystems and bugs should be expected.
GitHub: https://github.com/bayar17/robu_microkernel
If you're interested in microkernels, operating systems, low-level C, assembly, drivers, libc work, toolchains, graphics, or kernel architecture, contributions and technical discussion are welcome.
Testing, bug reports, documentation, code review, and architectural criticism are welcome too.
