Operating System in 1,000 Lines – Intro
https://operating-system-in-1000-lines.vercel.app/enI wrote this book so you can spend a boring weekend writing an operating system from scratch. You don’t have to write it in C - you can use your favorite programming language, like Rust or Zig.
I intentionally made it not UNIX-like and kept only the essential parts. Thinking about how the OS differs from Linux or Windows can also be fun. Designing an OS is like creating your own world—you can make it however you like!
BTW, you might notice some paragraphs feel machine-translated because, to some extent, they are. If you have some time to spare, please send me a PR. The content is written in plain Markdown [1].
Hope you enjoy :)
[1] https://github.com/nuta/operating-system-in-1000-lines/tree/...
Making video game is also like creating your own world!
And it's order of magnitude less hard than making an OS...
Bonus point, you have a chance to make a living from it!
Also I'm not speaking about making a game engine along with the game.
Having a kernel dev job is different than making your own kernel, speaking on a "world builder" perspective.
The Tanenbaum book is great but it is a particle physics textbook compered to this OS cookbook.
QEMU contains a built-in GDB server, you'll need a GDB client built for the target architecture (riscv in this case) and connecting to the QEMU GDB server over the network.
1) Record & Replay: Record an execution and replay it back. You can even attach GDB while replaying, and go back in time while debugging with "reverse-next" and "reverse-continue": https://qemu-project.gitlab.io/qemu/system/replay.html
2) The QEMU monitor, especially the "gva2gpa" and "xp" commands which are very useful to debug stuff with virtual memory
3) "-d mmu,cpu_reset,guest_errors,unimp": Basically causes QEMU to log when your code does something wrong. Also check "trace:help", there's a bunch of useful stuff to debug drivers
Thankfully, GDB has a multiarch build these days which should work for all well-behaved targets in a single build.
(the place it is known to fail is for badly-behaved (embedded?) targets where there are configuration differences but no way to identify them)
Is there any real hardware that this could run on?
Looking through this seems to use a lot of assembly. In the above the amount of assembly is kept to a minimum. Pretty much just bootstrapping and context switching. The rest is done in C.
Apples to oranges, though. It was a specialized firmware system. Probably the biggest part was the IEEE-488 communications handler.
Looks like more like 2800 lines.
[0] https://littlegreenviper.com/wp-content/uploads/2022/07/TF30...
https://operating-system-in-1000-lines.vercel.app/en/17-outr...
They bothered to stop and suggest improvements here. That's enough work for them. They don't need to go elsewhere and do more, any more than you did.
As an industry are we not supposed to be trying to move away from hoary old unsafe C?
Could we not have a hobbyist educational OSes in more of the C replacements?
Drew DeVault wrote Bunnix in Hare, in one month. There's the proof of concept.
How about tiny toy Unix-likes in Zig, Nim, Crystal, Odin, D, Rust, Circle, Carbon, Austral?
How about ones that aren't ostensibly suitable for such tasks, such as Go or Ada?
Yes I know Ada is not a good fit, but there has already been a Unix-like OS entirely implemented in a derivative of Pascal: TUNIS.
https://en.wikipedia.org/wiki/TUNIS
This might need work from skilled expert practitioners first. That's good. That's what experts are for: teaching, and uplifting newbies.
There was a project to do C# on the bare metal.
https://migeel.sk/blog/2023/12/08/building-bare-metal-bootab...
How about a Unix-like in C#? Get the Unix and .NET folks interested in this stuff.
Even if the OS never leads to anything, maybe the tooling might prove useful. I am sure someone somewhere would have uses for bare-metal GoLang.
Saying that, I really don't think we need any more Unix-like OSes. There are far far too many of those already. There is a huge problem space to be explored here, and there used to be fascinating OSes that did things no Unix-like ever did.
OSes that are by modern standards tiny and simple but explored interesting areas of OS design, and are FOSS, with code out there under permissive licenses:
* Plan 9 https://github.com/plan9foundation/plan9
* Inferno https://github.com/inferno-os/inferno-os
* Symbian https://github.com/SymbianSource
* Parhelion HeliOS https://archive.org/details/Heliosukernel
There is already an effort at Plan 9 in Rust:
https://github.com/dancrossnyc/r9
Why not Plan 9 in Zig, or Hare, or even D?
Plan 9 imposes and enforces considerably more simplicity on C as it is: you can't #include stuff that already has #include statements of its own. The result is a compilation speedup of around 3 orders of magnitude. That would be a benefit to the would-be C replacements too, wouldn't it?
Isn't it? There is a very well-developed kernel written in ADA with SPARK and formally verified at that: https://ironclad.nongnu.org
And PASCAL-derived languages were very popular for operating systems in the 80s. To name a few: Apple's LISA OS, DEC's VAXELN, and OBERON. There were others as well that didn't quite make it, like DEC's MICA and Acorn's ARX.
Why?
> https://en.wikipedia.org/wiki/TUNIS
Interesting; do you know whether the source code is available somewhere?
Most of them don't seem to understand how anything substantially different could exist in the world of computing - every other language and operating system is seen as either an inferior copy, or as another layer of abstraction building on top of C and UNIX.
Besides, what's the point of this comment? What if people wanted to write a million more Unix-like kernels in C? Do you think this is bad? Why do you care? If you want, just write your own in whatever language you want, with whatever design you want.
> Why not Plan 9 in Zig, or Hare, or even D?
Because nobody to this point was interested in doing this. It's really that simple.
"Make your own kernel" is a thing-in-itself, and "runs on <X> hardware/VM" + "provides <Y>-like API for programs" are tangible, concrete goals to aim for, even if you personally don't like the <Y> API or the architectural choices it implies.
To give an analogy: https://www.nand2tetris.org/ is an amazing learning experience, even though games other than Tetris should and do exist
Personally, I like the AROS project, aiming to provide an operating system that implements the AmigaOS APIs and runs on many architectures, but lots of users are interested in running it on 680x0 Amigas and spiritually-related PowerPC devices: https://en.wikipedia.org/wiki/AROS_Research_Operating_System
It's OK for programmers to write a thing just for the learning experience. If it gains adoptees, that's a happy accident.
Interesting. Thanks.
> Besides, what's the point of this comment? What if people wanted to write a million more Unix-like kernels in C? Do you think this is bad? Why do you care?
Because it seems to me that modern OS design is caught in a deep deep rut, and the "OS in 1000 lines" article that we are discussing is digging that rut even deeper.
Don't repeat the mistakes of the past. Make interesting new mistakes. It's more fun.
Now’s your chance to move the state of the art forward!
The Muen Seperation Kernel (muen.sk) is a secure hypervisor written in SPARK Ada.
Ada was designed for low-level programming. It makes sense it does operating systems fairly easily. Parts of them will break its safety features. They can be validated with external tools, though.
Another trick, used in House with H layer, is to wrap the lowest-level parts which you might do in assembly. Build the GC or whatever, too. Then, everything else is in the higher-level language. These data, the lowest-level portions can be specified, verified, and implemented.