The refactoring hell continues…

I’ve refactored PMM and VMM into SIMPLE_STATE, updated the build and docs scripts, enhanced kernel logging via log levels and more, added and fleshed out a Claude Code Skill for writing rustdoc and let Claude re-do a lot of the rust doc to reduce the over-documentation that was done by none other than… Claude.

also look at this fancy new fb logging :D

Refactoring into oblivion!

Currently working on improving the kernel a lot to make it robuster for its later stages.

What was so far improved

Tooling

• Replace loose markdown docs with proper GitHub Pages hosted rustdoc
• Add docs.py, refactor build.py to work on linux too

Kernel

• Serial Logging abstracted into trait + per-arch impls
• Improve panic handlers to give more info and dynamically use what is avail for outputting info (basic fb, serial)
• Refactor basic framebuffer and PSF2 font into cleaner struct+impl approach
• Remove text.rs and move its logic into kprint (which has also been refactored to be concurrency-safe)

Other Stuff

I also tested the kernel on real hardware!!
To my suprise, grabbing the ISO from the build folder, flashing it onto a USB drive and plugging it into a laptop just… WORKED?!?

well i guess my kernel is real hardware certified now :)

I attached a video of the kernel booting on real hardware and IRQ0 (the BIOS-configured 18.2 Hz hardware timer) printing “a” repeatedly. :)

Big Update :)

(sorry for not doing much the past weeks had to get 4th place at the botball competition real quick)

Changelog

• Implemented heap allocator (partially and broken)
• Implement PIC (Programmable Interrupt Controller) Init + get basic IRQ stuff working
• Fix GDT (was missing a few entries)
• Fix TSS (IST1-4 interrupt stacks were missing)
• Implement interrupts for vectors #0 through #31
• Update Panic for most interrupts to give way more details (example: pagefault in attached image)
• Replace Mutex with IrqMutex for text writing and holding CHAINED_PICS

Current State

I’ve noticed that my so far work has been kinda sloppy, so I’m currently working on improving everything (as u can see on the changelist above ive already started). I’m doing this because when I started with IRQs, stuff started breaking a lot. My goal is to get everything thread-safe and ready in a way that it’ll work in later stages of the kernel too.

Next up?

Next, I’ll be working on fixing logging (add a ringbuffer to prevent interrupts creating half-printed or partially drawn logs)

Had a little fight with github actions and qemu wasm stuff.

Tried to implement a live web demo using a wasm implementation of qemu with UEFI and more, but couldnt get it to run.

Also, I heavily improved documentation and finished up the virtual memory manager (for now…).

Plans?

Next, the heap allocator is coming then I’ll finally be able to use dynamic types!

was worth it i guess (it was not i gotta get up in 5h 🥲)

Hi!

This is my “main” project, ✨FerriteOS✨!

(Well, idk if you can call it a whole OS if im only planning to do a kernel, but anyways)

Ferrite is a Linux-ABI compatible kernel, written entirely in Rust, from scratch.

My goal

My end goal is for it to be able to run systemd, GNOME and more. But thats a very, VERY distant goal. For now, im focusing on getting a statically linked C binary running in userspace.

Current State

I’ve already managed to get some basic logging via serial and a basic framebuffer going, aswell as x86_64 GDT, IDT, TSS and a physical aswell as a very slim virtual memory manager.

Whats next?

Next, I’ll be “finishing” up the VMM a little to be able to start work on the heap allocator, which will enable use of datatypes like Vec, Box and more.

nerd section

For anyone interested in the more technical stuff:
The build toolchain works through python scripts, which use docker to build and then QEMU to run the kernel.
I’m mainly targeting x86_64, but aarch64 support is also my plan (but I’ll be focusing on x86_64 during this challenge).