Writing an operating system kernel from scratch

Zig really is amenable to OS development. And so is RISC-V. I started this same exercise except with x86 first. I quickly got annoyed with all the legacy boilerplate required. RISC-v doesn’t have any of that. It’s so much faster to get up and running. Here’s my bad zig: https://github.com/Fingel/aeros-v

> with x86 first. I quickly got annoyed with all the legacy boilerplate required.

IMHO, if you use a reasonable bootloader, you don't have too much boilerplate. Multiboot loaders do leave you in real mode, and most people want to be in protected mode, so you have to set up some tables and do a jump, but that's not that much boilerplate. There's a bit more stuff if you disable legacy interrupt controllers (which you probably want to) but it seems to me being able to maybe run on a regular pc is worth it (caveats about console interfaces apply... my hobby OS needs bios boot and uses some vga things that I found aren't well supported... serial console is easier, but lots of computers don't have a serial port either)

You still have to set up the GDT, TSS, all that other legacy stuff that isn't actually used but it's still there. And if you set it up incorrectly, your punished for it with triple faults and the like, even if nobody even uses anything like the GDT or TSS these days.

I’d like to have a go at this. What are you using to run your risc-v kernel? Just Qemu or can you recommend any real hardware?

Just Qemu. I used this as a guide: https://operating-system-in-1000-lines.vercel.app/en/ It's C so translating to Zig is pretty fun.

that is a pain. oswiki is a good resource, and there are also a huge number of examples. but it still takes a day. context save and restore and interrupts is another speed bump. but its no different than any other development banging your head against the wall exercise, and its pretty rewarding to have smoothed all that over and go to town on bespoke scheduler design.

I dunno, I've done it myself, and I would say that it's qualitatively different than other "banging your head against the wall" software development. At least it's an order of magnitude more painful, due to lack of integrated tooling, questionable documentation, and a more delayed feedback loop.

Single-threaded kernel bringup is easier than most distributed systems though.

Funnily enough, when I was writing one in Zig for x86 I actually was the one who found a bug in (I think) 0.11/0.12 where packed structs broke when you assigned to their fields (and I also found that the `.interrupt` calling convention was a todo item in that version). GDT/TSS is always, always one of the most annoying parts of an x86 OS for me, because all of it is so tedious and unnecessary, and I wish Intel would just get rid of IA32 mode already, or add some kind of bit in CR0 or CR4 which caused all that extraneous setup of legacy structures to just cease to be. RISC-V is so, so much more pleasant to get started with. Limine helps regardless of which architecture your getting going with; it's pretty much my de facto bootloader at this point.

Setting up the GDT is exactly the point where I got annoyed enough to see what risc-v was all about.

Yep, agreed. Don't get me wrong, the Intel/AMD docs are amazing. But even getting the hardware to a usable state (where I define usable as "something that can enumerate PCI devices on the system, even without PCIe") is an absolute pain that really just shouldn't exist. I know that RISC-V ahs it's own tough spots but... IMO it's a lot faster to get up and running with because it doesn't have 10000 execution modes with tons of different requirements you need to do for each mode, and on and on and on and on. (Yes, I'm exaggerating a bit.)

Naturally, it is basically revisiting the safety of Object Pascal and Modula-2, and repacking it into a C syntax.

C was never special, beyond being widely available thanks to UNIX original licensing.