I have redone the classical exercise of writing a tiny OS kernel with time sharing, which manages a couple of user threads. My goal was to experiment specifically on RISC-V + OpenSBI. Additionally, I wanted to explore Zig a little bit, so that was the language used instead of the traditional C, but it should be straightforward how to do the same experiment in either C or Rust.
It's definitely very rough around the edges, and it's more of an experiment and an intro for people who want to go through step 0 of learning OS kernel development and computer architecture. Nevertheless, I hope it is still a fun experimental thing to play with over the weekend!
The full walkthrough and the GitHub link are available at the link posted!
I will never not find this kind of project incredibly impressive. It’s interesting to think that Linux, after all, is really just the kernel — and yet getting that work done paved the way to getting an open source version of Unix installed on billions of machines. Great stuff!
It's even more funny and amusing when you remember that in the initial release mail for Linux, Torvals said "just a hobby, won't be big and
professional like gnu".
> I will never not find this kind of project incredibly impressive
I wouldn’t call it incredibly impressive. The path on how to write a minimal multi-tasking kernel has been beaten decades ago.
Writing a kernel that can boot and do a few things is ‘just’ a matter of being somewhat smart and have some perseverance. Doing it for RISC-V complicates things a bit compared to x86, but there, too, the information about initialising the hardware often is easily obtained (for example: https://wiki.osdev.org/RISC-V_Meaty_Skeleton_with_QEMU_virt_... I wouldn’t know whether this project used that)
I think the author agrees, given (FTA) that they wrote “This is a redo of an exercise I did for my undergraduate course in operating systems”
It’s work, may be nice work, but I think everybody with a degree in software engineering could do this. Yes, the OS likely will have bugs, certainly will have rough edges, but getting something that can multi-process, with processes shielded from each other by a MMU isn’t hard anymore.
Tanenbaum's book is worth getting but it's now been almost 20 years since it was published—the Minix it documents is substantially different from the state that Minix was left in when the VU students stopped working on it and that's available on minix3.org—itself by now 10 years old. (That doesn't make the version corresponding to the book at the time of original publication inaccessible, but the temptation is there.) There's the minor problem that the design in Minix isn't representative of the designs of familiar real world systems that aren't microkernels, too.
It is equally valid to say that Stallman's starting to write a C compiler and Unix utilities (in 1984 whereas the Linux project started in late 1991) paved the way to getting an open source version of Unix installed on billions of machines.
I agree - there's a number of kernels that were "open source" and released at a similar time enough time to linux (e.g. 386BSD in '92) that I could see any of those winning the "community battle" and taking that space instead, but no real credible "development toolchain" equivalent until decades later.
Though I'm unsure how differing licenses might have affected this - I suspect that really early in it's development the "copyleft" nature of the GPL Linux didn't make as much of a difference, as from what I remember most commercial uses of Linux didn't come until it had already gained significant momentum.
The copyleft nature was essential to good driver support. It set it up such that for corporations making drivers the easiest path was to get the driver upstreamed. There was a bunch of hoops they could have gone through to avoid that (as many did, like Nvidia) but that became a sorta-default.
Copyleft encourages a collaborative relationship between entities because it makes trying to play it close to the chest with IP involve more legal effort (if it's possible at all).
Yes, I can see that stalling development as (at best) it turns into a pile of private forks rather than a cohesive project, but from what I remember that was already after Linux had "won" the "Open Source Kernel" race.
Commercial support for Linux was... Sparse... before the early 2000s.
> [Stallman/GNU] getting an open source version of Unix installed on billions of machines.
Agreed, funnily enough GNU tools/compilers also ended up getting installed on a lot of proprietary UNIXes because proprietary UNIX was mostly shit (in user space!). At least most of the ones I had the misfortune to have to work on.
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.
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.
> El acceso a la presente dirección IP ha sido bloqueado en cumplimiento de lo dispuesto en la Sentencia de 18 de diciembre de 2024, dictada por el Juzgado de lo Mercantil nº 6 de Barcelona en el marco del procedimiento ordinario (Materia mercantil art. 249.1.4)-1005/2024-H instado por la Liga Nacional de Fútbol Profesional y por Telefónica Audiovisual Digital, S.L.U.
> https://www.laliga.com/noticias/nota-informativa-en-relacion...
I heard about this situation in Spain where Cloudflare (and maybe others) are blocked by mistake due to being associated with some sites streaming football.
How are people getting around this problem, I guess VPN? I mean, some of the wrongly blocked IPs are needed for work I imagine.
I don't have a first version visionfive2 myself, but i heard good things about it and the eco-system sounds like it's growing. There are still rough edges. Lets hope they ship soon (tm)
Edit: What I currently have for my personal projects is a PolarFire SoC Discovery Kit. That's a quad-core RISC-V system with FPGA embedded. Maybe too expensive and not for everyone (130 bucks, fun fact: The dev board is cheaper than the chip itself).
Also the microchip documentation, toolchain and so forth feel really crappy and old, but once you get used to it, it's not that bad and actually getting to run bare-metal risc-v code is easy. There are easy examples for linux and bare-metal
Submitted separately by the author:
https://news.ycombinator.com/item?id=45236479
Copying their comment to here:
I have redone the classical exercise of writing a tiny OS kernel with time sharing, which manages a couple of user threads. My goal was to experiment specifically on RISC-V + OpenSBI. Additionally, I wanted to explore Zig a little bit, so that was the language used instead of the traditional C, but it should be straightforward how to do the same experiment in either C or Rust.
It's definitely very rough around the edges, and it's more of an experiment and an intro for people who want to go through step 0 of learning OS kernel development and computer architecture. Nevertheless, I hope it is still a fun experimental thing to play with over the weekend!
The full walkthrough and the GitHub link are available at the link posted!
I will never not find this kind of project incredibly impressive. It’s interesting to think that Linux, after all, is really just the kernel — and yet getting that work done paved the way to getting an open source version of Unix installed on billions of machines. Great stuff!
It's even more funny and amusing when you remember that in the initial release mail for Linux, Torvals said "just a hobby, won't be big and professional like gnu".
https://groups.google.com/g/comp.os.minix/c/dlNtH7RRrGA/m/Sw...
He's also referred to Linux as "the GNU Emacs of all terminal emulators".
> It's now the GNU Emacs of all terminal emulators.
> (Linus Torvalds, regarding the fact that Linux started off as a terminal emulator.)
http://neil.franklin.ch/Jokes_and_Fun/Linux_Quotes.html
That's the best reference I can find, but even if it's totally legit it doesn't make any sense to me.
Perhaps it's a reference to how Emacs does "everything" and some has also joked that Emacs is an OS with a text editor
> I will never not find this kind of project incredibly impressive
I wouldn’t call it incredibly impressive. The path on how to write a minimal multi-tasking kernel has been beaten decades ago.
Writing a kernel that can boot and do a few things is ‘just’ a matter of being somewhat smart and have some perseverance. Doing it for RISC-V complicates things a bit compared to x86, but there, too, the information about initialising the hardware often is easily obtained (for example: https://wiki.osdev.org/RISC-V_Meaty_Skeleton_with_QEMU_virt_... I wouldn’t know whether this project used that)
I think the author agrees, given (FTA) that they wrote “This is a redo of an exercise I did for my undergraduate course in operating systems”
It’s work, may be nice work, but I think everybody with a degree in software engineering could do this. Yes, the OS likely will have bugs, certainly will have rough edges, but getting something that can multi-process, with processes shielded from each other by a MMU isn’t hard anymore.
To you maybe. The subset of population that is even interested, smart, persevering to do this is extremely tiny.
Is there a book one can read to learn how to create one?
https://en.wikipedia.org/wiki/Operating_Systems:_Design_and_...
Tanenbaum's book is worth getting but it's now been almost 20 years since it was published—the Minix it documents is substantially different from the state that Minix was left in when the VU students stopped working on it and that's available on minix3.org—itself by now 10 years old. (That doesn't make the version corresponding to the book at the time of original publication inaccessible, but the temptation is there.) There's the minor problem that the design in Minix isn't representative of the designs of familiar real world systems that aren't microkernels, too.
It's also not free.
As an alternative/complement to Tanenbaum, here's a 2025 version of the xv6 book: <https://pdos.csail.mit.edu/6.S081/2025/xv6/book-riscv-rev5.p...>
> I think everybody with a degree in software engineering could do this
Ideally this would be true, but it hasn't been my experience at all. At least with American graduates, I can't speak to other countries.
It is equally valid to say that Stallman's starting to write a C compiler and Unix utilities (in 1984 whereas the Linux project started in late 1991) paved the way to getting an open source version of Unix installed on billions of machines.
I agree - there's a number of kernels that were "open source" and released at a similar time enough time to linux (e.g. 386BSD in '92) that I could see any of those winning the "community battle" and taking that space instead, but no real credible "development toolchain" equivalent until decades later.
Though I'm unsure how differing licenses might have affected this - I suspect that really early in it's development the "copyleft" nature of the GPL Linux didn't make as much of a difference, as from what I remember most commercial uses of Linux didn't come until it had already gained significant momentum.
The copyleft nature was essential to good driver support. It set it up such that for corporations making drivers the easiest path was to get the driver upstreamed. There was a bunch of hoops they could have gone through to avoid that (as many did, like Nvidia) but that became a sorta-default.
Copyleft encourages a collaborative relationship between entities because it makes trying to play it close to the chest with IP involve more legal effort (if it's possible at all).
Yes, I can see that stalling development as (at best) it turns into a pile of private forks rather than a cohesive project, but from what I remember that was already after Linux had "won" the "Open Source Kernel" race.
Commercial support for Linux was... Sparse... before the early 2000s.
> [Stallman/GNU] getting an open source version of Unix installed on billions of machines.
Agreed, funnily enough GNU tools/compilers also ended up getting installed on a lot of proprietary UNIXes because proprietary UNIX was mostly shit (in user space!). At least most of the ones I had the misfortune to have to work on.
[dead]
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.
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’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.
> El acceso a la presente dirección IP ha sido bloqueado en cumplimiento de lo dispuesto en la Sentencia de 18 de diciembre de 2024, dictada por el Juzgado de lo Mercantil nº 6 de Barcelona en el marco del procedimiento ordinario (Materia mercantil art. 249.1.4)-1005/2024-H instado por la Liga Nacional de Fútbol Profesional y por Telefónica Audiovisual Digital, S.L.U. > https://www.laliga.com/noticias/nota-informativa-en-relacion...
Of FFS...
one thing is using http but another this one…
I heard about this situation in Spain where Cloudflare (and maybe others) are blocked by mistake due to being associated with some sites streaming football.
How are people getting around this problem, I guess VPN? I mean, some of the wrongly blocked IPs are needed for work I imagine.
...what? a football organization in Spain has the power to restrict internet access to the entire country?
Yes, that is exactly what is happening
Football is really big in Spain dontcha know?
How does one get their hands on low-cost RISC hardware?
There's this $10 board on Aliexpress called Milk-V Duo S. It's been popping up on my recs every now and then. Looks interesting.
https://aliexpress.com/w/wholesale-Milk%2525252dV-Duo-S.html
Taken directly from its description:
>Milk-V Duo S is an upgraded model of Duo with an upgraded SG2000 master with a larger 512MB RAM and extended IO capability
>Onboard WI-FI6/BT5(Model Milk-V-Duo-S-512M-Basic/Milk-V-Duo-S-512M-eMMC does not have this function)
>USB 2.0 HOST port
>100 Mbps Ethernet Portwith PoE Support (via PoE HAT)
>Dual MIPI CSI with ISP
>The device also supports switch between RISC-V and ARM boot via a switch
I think there are dozens of boards by now, but what I found interesting and pledged to is this:
https://www.kickstarter.com/projects/starfive/visionfive-2-l...
I don't have a first version visionfive2 myself, but i heard good things about it and the eco-system sounds like it's growing. There are still rough edges. Lets hope they ship soon (tm)
Edit: What I currently have for my personal projects is a PolarFire SoC Discovery Kit. That's a quad-core RISC-V system with FPGA embedded. Maybe too expensive and not for everyone (130 bucks, fun fact: The dev board is cheaper than the chip itself).
https://www.microchip.com/en-us/development-tool/MPFS-DISCO-...
Also the microchip documentation, toolchain and so forth feel really crappy and old, but once you get used to it, it's not that bad and actually getting to run bare-metal risc-v code is easy. There are easy examples for linux and bare-metal