nuta

I thinks this 1,000 OS book is a good start for beginners before diving into the MINIX book.

MINIX book describes more practical designs, with a more feature-rich implementation. However, UNIX features such fork, brk, and tty are not intuitive for beginners. By writing a toy OS first, readers can compare the toy OS with MINIX, and understand that UNIX-like is just one of many possible designs. That's an important perspective IMO.

Also, readers can actually implement better algorithms described in the MINIX book. It makes the MINIX book more interesting to read.

Thank you! If you've written some programs (ideally in C), you're good to go. You might stuck on some concepts, but you can learn one by one. IMO, implementing it makes you to understand the concepts more deeply, and learn more that you won't notice when you just read textbooks.

Also, because the implementation in this book is very naive, it would stimulate your curiosity.

Thank you. My efforts on preparing both EN/JP translations paid off :D

No it's "left as an exercise to the reader" ;)

But seriously, it's not that hard. Change build options to generate 64-bit ELF, replace all 32-bit-wide parts (e.g. uint32_t, lw/sw instructions), and implement a slightly more complicated page table (e.g. Sv48).

Copy-and-pasting to ChatGPT. Machine translation (JP to EN) before this LLM era was already high quality, but LLM does a really great job. It does not translate as is, but understands the context, drops unnecessary expressions (important!), and outputs a more natural translation.

That said, LLM is ofc not perfect, especially when the original text (or Japanese itself) is ambiguous. So I've heavily modified the text too. That's why there are some typos :cry:

Unfortunately not. Maybe I'll write another online book like this in English, after building a more practical microkernel-based OS. It's a very interesting topic indeed :D

TIL. It's too late for this book, but I'll try it in the next one.

So do I :D

I was wondering that too. I'll update it with other examples (x86 and Arm).

Author here.

I 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/...

Good point. As you say Kerla lacks unit tests I focused on running a SSH server as soon as possible.

IMO, writing and running tests in the kernel space is pretty easy thanks to Rust’s flexible testing feature [1].

[1]: https://os.phil-opp.com/testing/

I’m not sure this answers what you asked, objects that are referenced from multiple objects are simply wrapped with Arc<T>.

About 3-4 months in total: took 1.5 month to run a simple Hello World program, 1 month to implement bunch of system calls, and another 1 month to implement features essential to run Dropbear SSH server (tty/pry, bug fixes, …).

In addition to its huge contribution to OS development in Rust, as a microkernel enthusiast, it sounds exciting to writing a microkernel in Rust, in the "Everything is a URL" principle. Moreover, it can run a good-looking GUI on a real machines [1]! I know it's very hard to be realized.

Aside from Redox, I'd mention Tock [2], an embedded operating system. It introduces a novel components isolation using Rust's power. I believe this field is where Rust shines and am looking forward to seeing it in production.

[1]: https://www.redox-os.org/screens/ [2]: https://www.tockos.org

The most challenging point is, as others said, the lack of the compatibility with Linux Driver API. I believe it would be really hard to implement and keep following changes in Linux.

An idea in my mind is to use Kerla for virtualized environments like KVM where only limited device drivers are needed (virtio for example).

Thanks! By the way, your MUTEX_WITH macro looks pretty interesting to me. I've never seen the idea.

Thanks! I'll keep doing Just for Fun :D

Author here. I've made the demo system public [1] but it's written just for me so it should be painful to set up the same environment.

The mechanism is pretty simple: a Node.js server (running on genuine Linux) listens on tcp:22. Once you connect, it boots a dedicated Firecracker microVM instance and forwards network packets between your SSH client and VM.

Regarding the command history, others (including I) can't see what you type. If you could, it must be a vulnerability.

[1] https://github.com/nuta/kerla-demo

Author here. I'm surprised to see my hobby project on Hacker News.

I know this kind of stuff spark the ``it's meaningless to rewrite everything (especially Linux) in Rust'' debate. I agree 100% that rewriting Linux in Rust (or your favorite language) is just a waste of time and such a project won't live long.

That said, what I'd say here is that it's fun. Really fun. Implementing ABI compatibility requires you to understand under the hood of the kernel. You can learn how printf(3) works. You can learn what happens before main().

Especially, in Rust, it's inspiring to explore ways to write a kernel safely and expressively. One of my favorite part is the implementation of read system call [1].

Lastly, You can try this OS on SSH. Hope you enjoy :)

    ssh [email protected]

[1]: https://github.com/nuta/kerla/blob/main/kernel/syscalls/read...