Ask HN: Where to start writing a OS/kernel?
15 comments
Hi. I'm pretty far down this road.
https://osdev.org is the defacto reference. Start with AMD64, don't bother with x86 (32-bit). Segmentation is a nightmare and there are less quirks with AMD64.
If/when you start reading the CPU manuals, use AMD's documentation. It's better than Intel's.
Write a toy kernel. The kernel is the first thing anyway and you'll need to know how it works to understand the rest. It defines the interface between userspace and the hardware. You have to define this yourself.
Second resource is #osdev on Libera. Be patient, ask good questions. Some of the smartest developers I've ever met hang out there, but their time is precious and you should know they have extremely strong opinions and are not afraid to share them (for better or worse). Incredible group of people that deserve a lot of respect.
I've written kernels in C and now my main OS (non-toy) kernel is in Rust. Rust is nice for this, but if you're learning then heed my advice and use C for some toy kernels to start. Otherwise the Rust stuff sort of gets in the way if you're not familiar both with the language and the concepts.
Get familiar with QEMU. Remember that it lies a lot when debugging kernels (issues it reports as bugs are most likely bugs in your kernel, for example). Don't bother with vbox/vmware for OS dev. They don't help much.
You can play with bootloaders to understand them (I do recommend) but remember they're annoying and it's generally better to start with a boot standard (such as Multiboot) so that GRUB/QEMU can boot into your kernel easier.
OSDev's wiki has a barebones guide. Follow it. Understand everything. It's imperative. Use GCC's annoying cross compilers as prescribed. Then you'll understand more why LLVM is easier to work with later on and will understand how cross compilation works. This will be important if/when you finally switch to Rust, too.
Finally, there's Reddit's r/osdev. It's less active and sometimes you get nasty Redditors responding, but there are a few frequents that are extremely helpful.
You can alternatively start with ARM if that's your fancy. Just know debugging and testing is more convoluted and there are less resources for beginners. #osdev people tend to like ARM more but seem to know more about x86 in general.
Hope that helps.
https://osdev.org is the defacto reference. Start with AMD64, don't bother with x86 (32-bit). Segmentation is a nightmare and there are less quirks with AMD64.
If/when you start reading the CPU manuals, use AMD's documentation. It's better than Intel's.
Write a toy kernel. The kernel is the first thing anyway and you'll need to know how it works to understand the rest. It defines the interface between userspace and the hardware. You have to define this yourself.
Second resource is #osdev on Libera. Be patient, ask good questions. Some of the smartest developers I've ever met hang out there, but their time is precious and you should know they have extremely strong opinions and are not afraid to share them (for better or worse). Incredible group of people that deserve a lot of respect.
I've written kernels in C and now my main OS (non-toy) kernel is in Rust. Rust is nice for this, but if you're learning then heed my advice and use C for some toy kernels to start. Otherwise the Rust stuff sort of gets in the way if you're not familiar both with the language and the concepts.
Get familiar with QEMU. Remember that it lies a lot when debugging kernels (issues it reports as bugs are most likely bugs in your kernel, for example). Don't bother with vbox/vmware for OS dev. They don't help much.
You can play with bootloaders to understand them (I do recommend) but remember they're annoying and it's generally better to start with a boot standard (such as Multiboot) so that GRUB/QEMU can boot into your kernel easier.
OSDev's wiki has a barebones guide. Follow it. Understand everything. It's imperative. Use GCC's annoying cross compilers as prescribed. Then you'll understand more why LLVM is easier to work with later on and will understand how cross compilation works. This will be important if/when you finally switch to Rust, too.
Finally, there's Reddit's r/osdev. It's less active and sometimes you get nasty Redditors responding, but there are a few frequents that are extremely helpful.
You can alternatively start with ARM if that's your fancy. Just know debugging and testing is more convoluted and there are less resources for beginners. #osdev people tend to like ARM more but seem to know more about x86 in general.
Hope that helps.
What if I don't know any C (and not interested in learning)? Should I still choose C over Rust then, provided I do want to learn Rust?
You're going to find more resources to get started on this in C. You might want to start by following guides etc in C until you can get a decent Hello World, maybe SMP (maybe not), and then see if you can do it again in Rust.
I'm going to offer some slight differences to junon's advice.
x86-32 is an ok target, and may be more approachable (more examples); do your best to get into 32-bit protected mode as soon as possible. You'll need to do that anyway for SMP, unless your chosen bootloader does it for you (most don't, but some do).
I personally would skip building a gcc cross compiler; I did it 20 years ago for Dreamcast hobby work, and llvm includes it out of the box. Save your frustration for other things.
Try to get a physical test box and use it frequently; I boot mine with PXE. Make sure you have a serial port between the test box and your dev box, because serial is a lot easier than VGA text or UEFI graphics.
Be aware that QEMU doesn't apply segment limits by default. This usually doesn't matter as you'll switch to protected mode and have unlimited segments most of the time... But it makes a difference in early boot and starting the non-boot processors.
I'm going to offer some slight differences to junon's advice.
x86-32 is an ok target, and may be more approachable (more examples); do your best to get into 32-bit protected mode as soon as possible. You'll need to do that anyway for SMP, unless your chosen bootloader does it for you (most don't, but some do).
I personally would skip building a gcc cross compiler; I did it 20 years ago for Dreamcast hobby work, and llvm includes it out of the box. Save your frustration for other things.
Try to get a physical test box and use it frequently; I boot mine with PXE. Make sure you have a serial port between the test box and your dev box, because serial is a lot easier than VGA text or UEFI graphics.
Be aware that QEMU doesn't apply segment limits by default. This usually doesn't matter as you'll switch to protected mode and have unlimited segments most of the time... But it makes a difference in early boot and starting the non-boot processors.
Yes. If you want to learn rust, then learn rust. It's a fun language. But kernel concepts are a different beast, and C is better suited for learning them.
I see, makes sense - I'll stick to C then. Thanks.
Have a look at the boundary layer at the top or bottom end of seL4 microkernel. I never knew embedded seL4 is in under iOS. There is a diagram in chapter 2 of the seL4 whitepaper comparing with traditional monolith the microkernel has fewer lines of code, in the ballpark of tens of millions vs tens of thousands.
seL4 is not what I'd recommend a newbie to kernel dev look at. It's a very complex project.
Good advice. These are all of the right answers.
IMO there’s a lot of yak shaving type stuff that a true beginner doesn’t need to worry about. Just going out and implementing something is more the way to go; worry about compilers and languages and tools is way out of scope for the beginner given the learning curve with concepts alone.
Here are some sites that provide instructions and examples for building operating systems:
[6.S081](https://pdos.csail.mit.edu/6.828/2019/index.html) (MIT, xv6 RISC-V, 2019), [6.828](http://pdos.csail.mit.edu/6.828/2018/xv6.html) (MIT, xv6 x86, 2018), [CS140e](http://web.stanford.edu/class/cs140e/) (Stanford, RPi C, 2019), [CS140e](https://downey.io/blog/cs140e-writing-an-operating-system-in...) (Stanford, RPi Rust, 2018, more on [HN](https://news.ycombinator.com/item?id=16134618), [Andre](https://github.com/rust-embedded/rust-raspi3-OS-tutorials) (RPi Rust, 2019), [CS140](http://www.scs.stanford.edu/12au-cs140/) (Stanford, 2012), [CS194-24](http://www.cs.berkeley.edu/~kubitron/courses/cs194-24-S13/in...) (Berkeley), [Baking Pi](http://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/) (Cambridge, RPi asm, 2012), [OS from Scratch](http://www.cs.bham.ac.uk/~exr/lectures/opsys/10_11/lectures/...) (Birmingham, more in [HN](https://news.ycombinator.com/item?id=8380822)), [OS Development](http://littleosbook.github.io/), (RIT Stockholm, more on [HN](https://news.ycombinator.com/item?id=13258063)), [these](http://news.ycombinator.com/item?id=4834008) (CMU, UMD, MIT, Stanford, Harvard), [BrokenThorn](http://www.brokenthorn.com/Resources/OSDevIndex.html), [bkerndev](http://www.osdever.net/bkerndev/index.php), [JamesM](http://www.jamesmolloy.co.uk/tutorial_html/) ... [OSDev.org](http://wiki.osdev.org/) is recommended in many sources. Here is a recent roundup on [HN](https://news.ycombinator.com/item?id=22087701), and [another](https://news.ycombinator.com/item?id=22149866) (both Jan 2020). This [textbook](http://csapp.cs.cmu.edu/) provides a recent overview of Unix + C OS.
[6.S081](https://pdos.csail.mit.edu/6.828/2019/index.html) (MIT, xv6 RISC-V, 2019), [6.828](http://pdos.csail.mit.edu/6.828/2018/xv6.html) (MIT, xv6 x86, 2018), [CS140e](http://web.stanford.edu/class/cs140e/) (Stanford, RPi C, 2019), [CS140e](https://downey.io/blog/cs140e-writing-an-operating-system-in...) (Stanford, RPi Rust, 2018, more on [HN](https://news.ycombinator.com/item?id=16134618), [Andre](https://github.com/rust-embedded/rust-raspi3-OS-tutorials) (RPi Rust, 2019), [CS140](http://www.scs.stanford.edu/12au-cs140/) (Stanford, 2012), [CS194-24](http://www.cs.berkeley.edu/~kubitron/courses/cs194-24-S13/in...) (Berkeley), [Baking Pi](http://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/) (Cambridge, RPi asm, 2012), [OS from Scratch](http://www.cs.bham.ac.uk/~exr/lectures/opsys/10_11/lectures/...) (Birmingham, more in [HN](https://news.ycombinator.com/item?id=8380822)), [OS Development](http://littleosbook.github.io/), (RIT Stockholm, more on [HN](https://news.ycombinator.com/item?id=13258063)), [these](http://news.ycombinator.com/item?id=4834008) (CMU, UMD, MIT, Stanford, Harvard), [BrokenThorn](http://www.brokenthorn.com/Resources/OSDevIndex.html), [bkerndev](http://www.osdever.net/bkerndev/index.php), [JamesM](http://www.jamesmolloy.co.uk/tutorial_html/) ... [OSDev.org](http://wiki.osdev.org/) is recommended in many sources. Here is a recent roundup on [HN](https://news.ycombinator.com/item?id=22087701), and [another](https://news.ycombinator.com/item?id=22149866) (both Jan 2020). This [textbook](http://csapp.cs.cmu.edu/) provides a recent overview of Unix + C OS.
A classic work is Operating Systems: Three Easy Pieces
It is free as in beer
https://pages.cs.wisc.edu/~remzi/OSTEP/
It is free as in beer
https://pages.cs.wisc.edu/~remzi/OSTEP/
Find a minimal set of syscalls somewhere and implement them. Everything else will flow naturally from there as you scratch your head. I wouldn’t read a book/watch lectures about kernel dev without having concrete motivation in the form of implementation challenges.
Operating Systems Design and Implementation 3rd Edition
by Andrew Tanenbaum (Author), Albert Woodhull (Author)
ISBN-10 : 0131429388
ISBN-13 : 978-0131429383
by Andrew Tanenbaum (Author), Albert Woodhull (Author)
ISBN-10 : 0131429388
ISBN-13 : 978-0131429383
Join the SerenityOS project and improve/add-to the kernel efforts there?
So I'd like to dive into this myself, as a means to have fun, experiment, learn and demystify.
Where should I start if I want to write a toy OS or kernel? For example, I've stumbled on the following resources until now, are they any good? Do you have any others to recommend?
- https://os.phil-opp.com/ (I don't know Rust, but I wanted to learn so this might be a good idea)
- https://pdos.csail.mit.edu/6.828/2022/xv6.html
Also, do you have any general tips/advice/insights in mind to share? Do you think it's a good idea for a hobby project?
Thanks in advance!