Sharkix MicroKernel - yet another x86-64 microkernel using capability handles
Posted: Fri Oct 02, 2026 10:27 pm
This is my current project that I feel is finally getting to the point where i'm happy to show other people.
Here's the repo link: https://github.com/GwenNelson/sharkix
It should build with basic gcc and make on linux, i've been building on Arch Linux - if anyone has trouble with building, please let me know. Make sure you do "git submodule update --init" too, for the externals, as it has my libfifo project as an external right now, though i'm thinking of pulling that in locally and refactoring to use sharkix's own sync.c instead of its own implementation of mutexes etc.
First of all, I want to be upfront and say: yes, I've used AI assistance for parts of it. I've got a long history of previous little kernel projects that didn't get very far; Sharkix has gotten WAY further while still being in its early stages. I'd ask people to read the code and commit history before dismissing it as just another vibe coded project. I haven't just been sitting here prompting and blindly integrating what the AI spits out. The architecture and design are mine, while I've used Codex for some bounded implementation work and, particularly earlier in development, to get some older pieces working. I'm gradually auditing, refactoring and rewriting those older parts as I go.
Currently it has a very basic PS/2 and Serial console driver (both in ring3), a round-robin scheduler with preemptive multitasking, IPC using kernel-managed FIFOs etc, it's capability based and syscalls deal with kernel-managed objects via capability handles only. It's not yet ready for SMP, and will need to be rewritten a lot to ensure that it's SMP-safe, but i'm trying to get the basic system architecture and ring3<>ring0 interface stable first before I heavily rewrite the core.
I was inspired to build Sharkix after some frustrations with seL4 - seL4 is legendary for formal verification, and that's obviously extremely valuable, but I found it a total pain to build because it uses an overly complicated build system for a microkernel, and I also want to have the microkernel able to launch multiple ELFs at startup instead of just one root task amongst many other little annoyances. seL4's build system is wonderful if you want to use the seL4 "ecosystem", but I found it annoying when trying to build something more lightweight, so I began Sharkix.
Right now, it's not a lot to look at - I only just earlier tonight got a basic skeleton shell running finally (try doing "make run-serial QEMU_DISPLAY=" if you want to test it out, it literally only has readline right now, but i'm sure people here can appreciate how much goes into that).
I'll also confess my sins upfront: not using a cross compiler yet, but i'm literally going to sort that out next. There's also all sorts of platform-specific code outside of the src/kernel/arch directory that I need to refactor still, and yes - I admit again that I used codex a lot to help generate some boilerplate code and right now most of memory.c too, which is why I intend to work on rewriting that entire module next too after I finish my current audit of the subsystems (there's some outstanding object lifetime bugs i'm aware of that i've been fixing as I go). My older projects have some old paging code i'm going to analyse and recycle for this, and I want to fix scheduler priorities and wait queues etc too.
Basically, like most projects it's got all sorts of random little stuff I need to fix - but I do now believe that it's at the point where it's more than just a "hello world" from a multiboot-compliant ELF and a boring AAAAAAABBBBBBB demo of multitasking, and therefore might be interesting enough for people here to review. I'd especially like people to take a look at my approach to IPC - for example, at first I decided to have call/reply, but i've now decided that can be implemented in a userspace library helper, and i'm planning on implementing "one-shot" reply caps that can be forwarded but only invoked once, which should allow for better performance for things such as the classic "POSIX personality talks to VFS server talks to filesystem server talks to block device cache talks to disk driver" chain, by just forwarding the cap for the buffer instead, so the disk driver can directly DMA into the userspace buffer etc. I have a lot of other ideas too that i've not yet documented.
Being honest, I fully expect people to find all sorts of little problems with my project, but I welcome that - after all, it's how we improve, right?
Oh, and although i've hung around this site for years, occasionally popping into IRC etc, this is my first actual post - so hi there
Here's the repo link: https://github.com/GwenNelson/sharkix
It should build with basic gcc and make on linux, i've been building on Arch Linux - if anyone has trouble with building, please let me know. Make sure you do "git submodule update --init" too, for the externals, as it has my libfifo project as an external right now, though i'm thinking of pulling that in locally and refactoring to use sharkix's own sync.c instead of its own implementation of mutexes etc.
First of all, I want to be upfront and say: yes, I've used AI assistance for parts of it. I've got a long history of previous little kernel projects that didn't get very far; Sharkix has gotten WAY further while still being in its early stages. I'd ask people to read the code and commit history before dismissing it as just another vibe coded project. I haven't just been sitting here prompting and blindly integrating what the AI spits out. The architecture and design are mine, while I've used Codex for some bounded implementation work and, particularly earlier in development, to get some older pieces working. I'm gradually auditing, refactoring and rewriting those older parts as I go.
Currently it has a very basic PS/2 and Serial console driver (both in ring3), a round-robin scheduler with preemptive multitasking, IPC using kernel-managed FIFOs etc, it's capability based and syscalls deal with kernel-managed objects via capability handles only. It's not yet ready for SMP, and will need to be rewritten a lot to ensure that it's SMP-safe, but i'm trying to get the basic system architecture and ring3<>ring0 interface stable first before I heavily rewrite the core.
I was inspired to build Sharkix after some frustrations with seL4 - seL4 is legendary for formal verification, and that's obviously extremely valuable, but I found it a total pain to build because it uses an overly complicated build system for a microkernel, and I also want to have the microkernel able to launch multiple ELFs at startup instead of just one root task amongst many other little annoyances. seL4's build system is wonderful if you want to use the seL4 "ecosystem", but I found it annoying when trying to build something more lightweight, so I began Sharkix.
Right now, it's not a lot to look at - I only just earlier tonight got a basic skeleton shell running finally (try doing "make run-serial QEMU_DISPLAY=" if you want to test it out, it literally only has readline right now, but i'm sure people here can appreciate how much goes into that).
I'll also confess my sins upfront: not using a cross compiler yet, but i'm literally going to sort that out next. There's also all sorts of platform-specific code outside of the src/kernel/arch directory that I need to refactor still, and yes - I admit again that I used codex a lot to help generate some boilerplate code and right now most of memory.c too, which is why I intend to work on rewriting that entire module next too after I finish my current audit of the subsystems (there's some outstanding object lifetime bugs i'm aware of that i've been fixing as I go). My older projects have some old paging code i'm going to analyse and recycle for this, and I want to fix scheduler priorities and wait queues etc too.
Basically, like most projects it's got all sorts of random little stuff I need to fix - but I do now believe that it's at the point where it's more than just a "hello world" from a multiboot-compliant ELF and a boring AAAAAAABBBBBBB demo of multitasking, and therefore might be interesting enough for people here to review. I'd especially like people to take a look at my approach to IPC - for example, at first I decided to have call/reply, but i've now decided that can be implemented in a userspace library helper, and i'm planning on implementing "one-shot" reply caps that can be forwarded but only invoked once, which should allow for better performance for things such as the classic "POSIX personality talks to VFS server talks to filesystem server talks to block device cache talks to disk driver" chain, by just forwarding the cap for the buffer instead, so the disk driver can directly DMA into the userspace buffer etc. I have a lot of other ideas too that i've not yet documented.
Being honest, I fully expect people to find all sorts of little problems with my project, but I welcome that - after all, it's how we improve, right?
Oh, and although i've hung around this site for years, occasionally popping into IRC etc, this is my first actual post - so hi there