HN user
This is open-source hardware, caveat emptor is implied.
At this stage in a project like this, I’d expect the people who were getting boards fabbed to also have the skills to sanity check the schematics and layout before they sent the gerbers off to China.
For me, one of the saddest side-effects of modern generative AI is this apparent rise in an attitude of “I don’t know how to do this, therefore anyone who does this must have just one-shotted it with AI”.
Even if we assume this _could_ be one-shotted, projects like this from respected members of the retro hardware community would be what made that one-shot even possible.
It isn’t, actually.
There would likely be value in a POSIX layer as you describe, at least from the point of view of porting existing programs. And perhaps it will happen, if I get far enough along, but it will never be a kernel feature - it would be an entirely userspace concept intended only to speed up porting and building out said user space.
Perhaps in the fullness of time essential software can be rewritten to Anos’ “native API”, or perhaps that’s a pipe dream and not worth the work, but the option will be there.
Thank you! A project like this is all about compounding small wins for sure, just building one thing on top of the previous thing until (hopefully) one day it’s a complete thing :D
I’m glad you found some inspiration and really appreciate your kind comment :)
I agree that for it to be generally useful, it’ll need to be easy to port existing software to. But I don’t think I’ll need a translation layer at the syscall level (unless I want to expose a Linux-compatible ABI as you suggest, which is totally a non-goal).
You can get surprisingly far in this area with a decent libc implementation - once you have that porting a lot of things becomes possible. There will always be harder problems (e.g. anything that hard-depends on fork) but with enough work pretty much anything in user-space should be possible to port eventually.
I’m using newlib for libc, with a custom Anos-specific libgloss that mostly talks to SYSTEM via IPC to get stuff done, and uses syscalls where needed (and a process has the appropriate capabilities). I’m filling out that low-level interface as I go, and will be using porting of exiting BSD or Linux software to drive that implementation :)
Haha that quote felt pretty much obligatory :D Non-POSIX is definitely keeping things fun, letting me explore different ideas without having to fit into an existing interface design :)
Thanks! I haven't thought much about long term to be honest, right now my immediate goal is to get enough USB HID to be able to make it interactive, with the medium term goal of porting enough software for it being self-hosting.
We live in an age of AI overinvestment. I would reserve judgement until they prove they actually have something.
Haha yes, that's a very fair comment!
There's ideas in here from various other kernels - some of the capability stuff is inspired by (but simpler than) seL4, and the message passing IPC and how I'll avoid priority inversion is based on ideas from QNX. Generally as a learning process I've tried to keep as open a mind as possible, without trying to reinvent all the wheels at once...
SYSTEM has a tiny arch-specific assembly trampoline which just sets up the initial stack pointer for new processes that it creates and makes the jump, but other than that it's source-compatible across architectures.
The platform detail extraction isn't yet complete, such that devices management on non-ACPI platforms isn't finished, but the idea is the abstraction will be enough that drivers for (at least) MMIO devices will be trivially portable.
That's a good way to look at it, and on reflection I feel the same way.
It's certainly useful _to me_ and has helped me really nail down concepts I thought I already understood, but it turns out I didn't.
I just hope that, in an age where it feels like code, and maybe even deep technical knowledge have diminishing value, projects like this don't become completely anachronistic.
Ahem, well, that's embarrassing! :D
It is hard, and things are messy in some areas. But in my experience it’s less hard than writing a lot of the existing documentation would’ve been (because good datasheets and documentation are more available now) and actually less messy (with some exceptions) than things were back in the days of the legacy hardware most existing wikis etc focus on.
Finding people with the knowledge, time and willingness to proof-read is also hard - but surely not insurmountable if we collectively decide it’s an endeavour we want to pursue.
This is really great work! Always impressed to see hobby OS projects that get this far, well done.
That said, I’m once again reminded that we sorely need some updated resources for aspiring OS developers in 2025. Targeting 32-bit x86 and legacy devices that haven’t been “the norm” for decades suggests to me a heavy influence from resources like the osdev wiki which, while occasionally useful, are increasingly outdated in the modern world and lead to many questionable choices early on.
I have come to believe (through multiple iterations of my own OS projects) that there’s more value in largely ignoring resources such as osdev and focusing instead on first-principles design, correct layering, and building based on modern platforms (be that x86_64 or something else) and ignoring legacy devices like the PIT and PS2 etc.
I just wish we had good introductory documentation resources to reflect that, and that outdated resources weren’t overwhelmingly surfaced by search engines and now AI “summaries”.
None of the above is intended to take away from OPs achievement, which is fantastic, or from the work done over the years by the osdev community, who I’m sure largely do the best they can with what they have.
Well put! This succinctly sums up the crux of my argument in my other comments.
Even taking only x86_64 as an example, going from real to long modes is primarily of concern to those writing firmware these days - a modern operating system will take over from UEFI or a bootloader (itself usually a UEFI executable). The details of enabling A20, setting up segmentation and the GDT, loading sectors via BIOS etc are of course historically interesting (which is fine if that’s the goal!) but just aren’t that useful today.
The primary issue with most tutorials that I’ve seen is they don’t, when completed, leave one in a position of understanding “what’s next” in developing a usable system. Sticking with x86_64, those following will of course have set up a basic GDT, and even a bare-bones TSS, but won’t have much understanding of why they’ve done this or what they’ll need to do to next to support syscall, say, or properly layout interrupt stacks for long mode.
By focusing mainly on the minutiae of legacy initialisation (which nobody needs) and racing toward “bang for my buck” interactive features, the tutorials tend to leave those completing it with a patchy, outdated understanding of the basics and a simple baremetal program that is in no way architected as a good base upon which to continue toward building a usable OS kernel.
While I agree this might be a fun resource and useful example code for various aspects of legacy x86 interfacing, I would urge anyone who hopes to actually get into OS development to ignore this (and in fact every other tutorial I’ve ever seen, including those hosted on the popular sites).
For all the reasons stated in the link from the README [1] and agreed by the author, this project should not be followed if one wants to gain an understanding of the design and implementation of operating systems for modern systems. Following it will likely lead only to another abandoned “hello world plus shell” that runs only in emulation of decades old hardware.
My advice is get the datasheets and programmers’ manuals (which are largely free) and use those to find ways to implement your own ideas.
Sorry for the confusion, I was referring to the putchar not being implemented in OPs code, I got yours working right away (nice work btw).
What you mention about VGA being common on x86 was what got me curious, since it’s not a thing on riscv. In my own OS project I’m using a framebuffer to show a graphical terminal on both x86 and riscv64 so I wondered if OP was doing similar or was really using SBI output.
Thanks! I see that you’re using the SBI routines, which is what I was expecting here but couldn’t find - the reference to “output text to VGA” in the post made me curious.
I did see the putchar stub in the user.zig but, lacking understanding of zig, wasn’t sure how that could work given common.zig is looking for putChar in kernel.zig as far as I could tell.
I just jumped through a couple of hoops to get zig 0.13 installed and see an error about “root struct of file ‘kernel’ had no member named ‘putchar’” so I guess maybe it’s not implemented here at all.
Nice work! Looks like most of the basics are covered, and meanwhile in my current kernel the RISC-V entrypoint is >700 lines (of C) just to get to the arch-independent entrypoint!
I was just looking around for your input/output code, I don’t know zig but I expected to find putChar in kernel.zig based on the import in common.zig, but I don’t see it, should I be looking somewhere else? I didn’t see any simple command line processing either as mentioned in the README?
Mostly just looking around since your README mentioned VGA (and you seem to have a BIOS boot) which struck me as interesting on a RISC-V project, I was curious if you were actually using the SBI routines or had actually mapped in a VGA text mode buffer?
Same here. I got a Bambu X1C and have been very happy with it.
Thank you!
At this early stage, the filesystem exists only to prove the disk drivers and the IPC interfaces connecting them. I chose FAT32 for this since there has to be a FAT partition anyway for UEFI.
The concept of the VFS may stick around as a useful thing, but it’s strictly for storage, there is no “everything is a file” ethos. It’s entirely a user space concept - the kernel knows nothing of virtual filesystems, files, or the underlying hardware like disks.
It's a bit disappointing that every time somebody decides to write their own kernel, the first thing they do is implement some subset of the POSIX spec.
Well, not quite _every_ time. For example, I’m deliberately not doing POSIX with my latest one[0], so I can be a bit more experimental.
It’s a very noticeable step down from cursor in terms of AI integration IMO, but also a huge step up in almost everything else.
For a while I was running both cursor and RubyMine in tandem and switching between as needed, but lately I’ve been using Claude code for most stuff, in a RubyMine terminal and I hardly miss cursor at all.
Our wonderful government “news” agency trying to legitimise this while also playing lip-service to balanced reporting: https://www.bbc.co.uk/news/live/cwy05zznyplt?post=asset%3A3e...
Nice article! Always good to see easy-to-follow explainers on these kinds of concepts!
One minor nit, for the “odd corner case that likely never exists in real code” of taken branches to the next instruction, I can think of at least one example where this is often used: far jumps to the next instruction with a different segment on x86[_64] that are used to reload CS (e.g. on a mode switch).
Aware that’s a very specific case, but it’s one that very much does exist in real code.
This fits my experience. I’m definitely getting considerably better results with 4 than previous Claudes. I’d essentially dropped sonnet from my rotation before 4 became available, but now it’s a go-to for this sort of thing.
I agree with this. Just the need to keep track of stack, flags and ad-hoc register allocations is something I’ve found they really struggle with. I think this may be why it does so much better at porting from one architecture to another - but even then I’ve seen it have problems with e.g. m68k assembly, where the rules for which moves affect flags are different from, say, x86.
I have, and to be fair that has solved the “basically incorrect code” issue with reasonable regularity. Occasionally the error messages don’t seem helpful enough for it, which is understandable, and I’ve had a few occurrences of it getting “stuck” in a loop trying to e.g. use an invalid addressing mode (it may have gotten itself out of those situations if I were more patient) but generally, with one of the Claude 4 models in agent mode in cursor or Claude code, I’ve found it’s possible to get reasonably good results in terms of “does it assemble”.
I’m still working on a good way to integrate more feedback for this kind of workflow, e.g. for the attempt it made at AP bootstrap - debugging that is just hard, and giving an agent enough control over the running code and the ability to extract the information it would need to debug the resulting triple fault is an interesting challenge (even if probably not all that generally useful).
I have a bunch of pretty ad-hoc test harnesses and the like that I use for general hosted testing, but that can only get you so far in this kind of low-level code.
I’ve been trying out various LLMs for working on assembly code in my toy OS kernel for a few months now. It’s mostly low-level device setup and bootstrap code, and I’ve found they’re pretty terrible at it generally. They’ll often generate code that won’t quite assemble, they’ll hallucinate details like hardware registers etc, and very often they’ll come up with inefficient code. The LLM attempt at an AP bootstrap (real-mode to long) was almost comical.
All that said, I’ve recently started a RISC-V port, and I’ve found that porting bits of low-level init code from x86 (NASM) to RISC-V (GAS) is actually quite good - I guess because it’s largely a simple translation job and it already has the logic to work from.