Stripping Away Abstractions: How I Built a Rust Microkernel from Scratch in 100 Hours (At Age 13)

Daxo — Sat, 20 Jun 2026 09:27:03 +0000

Most developers take the operating system for granted-treating it as an invisible, obedient foundation for browsers, Docker, and heavy IDEs. For me, this foundation was always the ultimate mystery. I wanted to understand: what actually happens on the bare metal when you strip away high-level abstractions?

That's how my 15-day experiment started. I carved out 100 hours from a tight schedule between school and intense martial arts training (judo and wrestling) to build a standalone, microkernel-based operating system from scratch: Daxo OS, written in Rust.

In this article, I’ll share how I broke free from standard tutorials, wrote a custom PIO ATA disk driver, brought async programming into Ring 0, and why Terry Davis and his legendary TempleOS became my ultimate engineering inspiration.

![Daxo OS in Action](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/nwiom7r5gtvtviq6h6yd.jpg)

Inspired by Madness: Why Bare-Metal?

If you ask a regular software engineer why they are writing their own OS, they might think you're crazy. But if you’ve ever read about Terry Davis and TempleOS, you understand that pure, unadulterated engineering excitement. Terry built his world without looking back at Linux or Windows-communicating directly with CPU registers and controllers.

I didn't want to build another CLI tool running on top of a ready-made Linux kernel. I wanted a system that manages physical hardware by my own rules. The choice was obvious: Rust Nightly. Its #[no_std] attribute allows writing blazing-fast code without a garbage collector while maintaining strict memory safety.

Here is the anatomy of Daxo OS:

daxo_os/ ├── .cargo/ │ └── config.toml # Linker settings and build flags ├── src/ │ ├── allocator/ # Custom heap allocators (Bump, Fixed Size Block) │ ├── task/ # Async engine (Executor, keyboard handling) │ ├── allocator.rs # Heap management interface │ ├── ata.rs # The custom PIO ATA hard drive driver │ ├── framebuffer.rs # Graphics output management │ ├── gdt.rs / interrupts.rs# Descriptor tables & interrupt handling │ ├── main.rs # Kernel entry point (kernel_main) │ └── vga_buffer.rs # Good old 80x25 text output ├── disk.bin # Disk image for QEMU testing └── x86_64-blog_os.json # Target platform specification

*The Tutorial Illusion and My First Triple Fault
*
Initially, like many OSdev beginners, I relied on Philipp Oppermann's amazing "Writing an OS in Rust" guide. Printing ASCII characters to the screen via direct VGA memory access at 0xb8000 is inspiring, but it's a linear experience. You are just following someone else's tracks.

Real engineering started where the guide ended. Since the modern Rust Nightly compiler moves fast, some older code broke. The rust-lld linker suddenly started throwing errors like undefined symbol: memcpy, and the kernel would plunge into a bootloop (Triple Fault) at the slightest mistake.

I realized that modern Rust editions require explicit encapsulation of raw operations inside unsafe blocks, even within unsafe fn in some contexts, alongside strict handling of compiler_builtins. Fixing this required diving into Cargo flags and manually rebuilding core libraries. It was the exact moment I transitioned from passively reading tutorials to hardcore systems research.
**
Hardware with No Safety Nets: Writing a PIO ATA Driver**

My main critique of existing OSdev tutorials is that they often abandon the reader halfway through. You get text output, you get keyboard interrupts, but the system remains a "black box"-it cannot persist data.

I decided to fix this by writing a custom PIO ATA driver for hard drive interaction.

The hard part? The OS needs to read disk sectors before the Interrupt Descriptor Table (IDT) and the Programmable Interrupt Controller (PIC) are fully set up. If the drive fires a hardware signal when the kernel isn't ready to catch it, you get an immediate crash.
I used an architectural hack: isolated port polling right before turning on interrupts.

Here is how the boot logic looks in my main.rs:
`#![no_std]

![no_main]

![feature(custom_test_frameworks)]

![test_runner(daxo_os::test_runner)]

![reexport_test_harness_main = "test_main"]

extern crate alloc;

use daxo_os::{print, println};
use core::panic::PanicInfo;
use bootloader::{BootInfo, entry_point};
use x86_64::VirtAddr;
use alloc::vec;

// Import structures for async multitasking
use daxo_os::task::{Task, keyboard};
use daxo_os::task::executor::Executor;

entry_point!(kernel_main);

async fn async_number() -> u32 {
42
}

async fn example_task() {
let number = async_number().await;
println!("async number from example_task: {}", number);
}

fn kernel_main(boot_info: &'static BootInfo) -> ! {
// 1. First, print the ASCII banner (works via VGA, interrupts are not needed yet)
println!(" ###### ### ## ## ####### ####### ###### ");
println!(" ## ## ## ## ## ## ## ## ## ## ## ## ");
println!(" ## ## ## ## ## ## ## ## ## ## ## ");
println!(" ## ## ## ## ### ## ## ## ## ###### ");
println!(" ## ## ######### ## ## ## ## ## ## ## ");
println!(" ## ## ## ## ## ## ## ## ## ## ## ## ");
println!(" ###### ## ## ## ## ####### ####### ###### ");

println!("\n[Daxo OS Multitasking Kernel Booted]");

// 2. Set up the memory mapper and heap (interrupts are still disabled)
let phys_mem_offset = VirtAddr::new(boot_info.physical_memory_offset);
let mut mapper = unsafe { daxo_os::memory::init(phys_mem_offset) };
let mut frame_allocator = unsafe {
    daxo_os::memory::BootInfoFrameAllocator::init(&boot_info.memory_map)
};

daxo_os::allocator::init_heap(&mut mapper, &mut frame_allocator)
    .expect("heap initialization failed");

// 3. --- ATA DRIVE DRIVER TEST IN COMPLETE ISOLATION ---
// PIC controller is not enabled yet, timer isn't ticking, nothing to crash!
println!("[Testing ATA Drive Driver...]");

let mut disk_vec = vec![0u8; 512];

if let Ok(disk_buffer) = <&mut [u8; 512]>::try_from(&mut disk_vec[..]) {
    daxo_os::ata::ATA_BUS.lock().read_sector(0, disk_buffer);

    println!("Data read from LBA 0:");
    let mut data_found = false;
    for &byte in disk_buffer.iter().take(90) {
        if byte >= 32 && byte <= 126 {
            print!("{}", byte as char);
            data_found = true;
        }
    }
    if !data_found {
        print!("[Sector contains binary data]");
    }
    println!("\n[ATA Test Finished]\n");
}
// ---------------------------------------------------------------------------------

// 4. NOW initialize IDT, GDT, and the PIC interrupt controller
// Any hardware signals from QEMU pending during the disk test will reset upon PIC initialization!
daxo_os::init(); 

#[cfg(test)]
test_main();

// 5. Create the task executor/scheduler
let mut executor = Executor::new();
executor.spawn(Task::new(example_task()));
executor.spawn(Task::new(keyboard::print_keypresses()));

// 6. Enable hardware interrupts on the CPU
x86_64::instructions::interrupts::enable();

// 7. Run the executor loop indefinitely
executor.run();

}

[cfg(not(test))]

[panic_handler]

fn panic(info: &PanicInfo) -> ! {
println!("{}", info);
daxo_os::hlt_loop();
}

[cfg(test)]

[panic_handler]

fn panic(info: &PanicInfo) -> ! {
daxo_os::test_panic_handler(info)
}`

To test the driver without a real file system, I used some Unix magic to write a test string into the first 512-byte sector of a blank disk.bin file:

echo "Daxo OS ATA Test String" | dd of=disk.bin bs=512 count=1 conv=notrunc

The conv=notrunc flag is critical here—it ensures dd overwrites only the initial bytes without truncating the disk image. I configured QEMU in Cargo.toml to mount this file as a hard drive on the IDE bus. When the kernel printed Daxo OS ATA Test String read directly from the controller ports, I knew it worked.

Async in Ring 0 Space

Once the disk is verified, control goes to a custom asynchronous task executor. Implementing async/await mechanics inside a custom kernel without the standard library is pure joy. There is no Tokio or async-std here.

The architecture relies heavily on raw Future and Waker types. When a task (like waiting for a keypress in keyboard::print_keypresses) cannot proceed, it yields, giving CPU cycles to other tasks. As soon as the PIC catches a keyboard interrupt, the handler wakes that specific Waker, and the executor resumes it. It runs concurrently and endlessly inside executor.run().

Conclusion: Real Engineering Starts Where Tutorials End

This 100-hour sprint taught me the most important lesson: don't panic when facing complete darkness. When you are looking at a raw terminal crash log with a low-level error you can't Google, the only way out is to read dependency source code, look up x86_64 architecture specifications, and understand the physics of the process.

Moving forward, I plan to take Daxo OS further: shifting from Ring 0 to Ring 3 (separating kernel and user spaces), exploring process isolation, and researching microkernel security mitigations.

👉 Check out the full source code here: github.com/aitoolsdx-glitch/daxo_os
(Drop a star ⭐ or open an issue if you want to roast my unsafe code or contribute!)

DEV Community: Daxo

Stripping Away Abstractions: How I Built a Rust Microkernel from Scratch in 100 Hours (At Age 13)

Inspired by Madness: Why Bare-Metal?

![no_main]

![feature(custom_test_frameworks)]

![test_runner(daxo_os::test_runner)]

![reexport_test_harness_main = "test_main"]

[cfg(not(test))]

[panic_handler]

[cfg(test)]

[panic_handler]