
Writing an OS in Rust - adamnemecek
http://os.phil-opp.com
======
dang
This is a dupe of
[https://news.ycombinator.com/item?id=10448136](https://news.ycombinator.com/item?id=10448136).
A related discussion was
[https://news.ycombinator.com/item?id=10569463](https://news.ycombinator.com/item?id=10569463).

------
VeilEm
I recently got started working with Rust and even though I have pretty decent
programming experience in statically typed languages Rust has been quite a
challenge. The borrow checker learning curve is very high. Even if you
understand the basics you won't always know what macros and functions will be
moving things until you run into an error. Lifetime management also requires a
bit of time to grok. Some things that are simple in almost any other language
can be frustrating in Rust, like someone wrote a book for how to write a
linked list in Rust.[0]

My advice is that when you're getting started with Rust, compile often. Don't
write a tome of code only to find out later it has no chance of compiling. It
gets easier the more you do it, so don't give up, but move in small steps.

[0] [http://cglab.ca/~abeinges/blah/too-many-
lists/book/](http://cglab.ca/~abeinges/blah/too-many-lists/book/)

~~~
nightpool
to be fair, that book covers 6 different types of linked lists, not just "how
to write a linked list". I could write a similarly-sized book (by word count)
on different types of linked lists in C++

~~~
VeilEm
Writing a linked list is pretty hard in Rust for someone new to the language.
Perhaps this wasn't as obvious from the book's introduction as I thought it
would be.

------
bluejekyll
So there is this, and there is also [http://www.redox-
os.org](http://www.redox-os.org). Are there any other OS' being built in Rust?

I'm curious about the intention of these two projects, this seems to be a
bottom up OS in Rust probably oriented toward unikernel or possibly a server
OS. To be successful I assume it's going to allow for NetBSD or Linux drivers
to be integrated into the Kernel in some way?

~~~
cmrx64
Me and some other people are working on a seL4-based OS in Rust. We're getting
ready to publically announce our first milestone by next week.

There's also
[https://github.com/thepowersgang/rust_os](https://github.com/thepowersgang/rust_os),
which is one of the oldest OS written in Rust, but never gets any press.

~~~
phil-opp
Yeah, thepowersgang's kernel is severely underrated.

------
kg6cvv
I spent a bunch of time figuring out how to get to long mode in a multiboot
kernel. Finally got it working and discovered that a 64 bit UEFI app _starts_
in long mode. Is it really so important to maintain support for non-UEFI
x86-64 systems?

~~~
legulere
My guess why it's done:

BIOS booting is still standard in all Virtual Machines and UEFI might even be
a pain in the ass to set up. This is where in the beginning your OS will run
most of the time.

Also UEFI has it's own pitfalls (the main function you have to provide and the
UEFI functions you can use use the windows calling ABI).

If you were to remove BIOS booting from an operating system that's actually
used you would get lots of complaints from people that a) have a system that
doesn't support UEFI b) are too lazy to switch on UEFI on their mainboard and
c) the most vocal group probably would be people that hate UEFI

------
leonardinius
Reminds me of
[https://github.com/intermezzOS/kernel](https://github.com/intermezzOS/kernel)

Do they work in parallel on same problem/same style/ veru similar codebases?
When why not to combine efforts?

~~~
polyfractal
If I understand correctly, Phil started writing his series first. That
tutorial prompted several people to start working on their own hobby OS,
including Steve's and another one here: [http://www.randomhacks.net/bare-
metal-rust/](http://www.randomhacks.net/bare-metal-rust/). I think Redox was
already underway when Phil started writing, but I may be mixing up my
timelines.

Edit: There is also [http://www.alexeyshmalko.com/2015/bkernel-a-rust-
operating-s...](http://www.alexeyshmalko.com/2015/bkernel-a-rust-operating-
system/)

Phil has stated his series is basically for fun and learning. I imagine
Steve's and Eric's are similar. You don't necessarily want to "combine effort"
with someone when you are exploring ideas on your own.

~~~
leonardinius
I mostly agree with you.

However part of it's effort is directed into producing tutorials/book material
for the educational etc use.

It's obviously up to 100% to them how and where are they going.

From the educational perspective it's _imo_ something worth considering at
some point. E.g. combining this collective know-how into some sort of book. I
know I would buy it.

~~~
steveklabnik
We are all very friendly with each other, and hang out in our IRCs, and #rust-
osdev. I expect the situation to be better for all of us, as we can cross-
pollinate, and improve each other's work. Ecosystems can be better than single
monolithic projects.

There are a LOT of decisions that can go into making an OS. The
compare/contrast in a few years should be really interesting.

------
matthewmacleod
This has been a very useful and educational project for me to follow – both in
terms of low-level kernel bootstrapping, and in terms of understanding Rust
and the tooling it provides. Absolutely love it and similar well-written
pieces like this.

~~~
phil-opp
Thanks a lot! New stuff is in the making :)

------
billconan
how do debug an OS? is the kernel debugger support from the OS, or it is from
an even lower level of the system?

Do you get the debugability automatically? or you have to code to support the
debugger?

~~~
jvns
the easiest way I found was to attach gdb to qemu (since you're normally
running the OS in an emulator). there are instructions for how to do this in a
comment on this blog post: [http://jvns.ca/blog/2013/12/04/day-37-how-a-
keyboard-works/](http://jvns.ca/blog/2013/12/04/day-37-how-a-keyboard-works/)

here are the instructions:

> Sam Rose Julia Evans • 2 years ago

> If you haven't yet experienced the joys of remote debugging with QEMU and
> gdb, you should totally try it out.

> Run qemu with the flag "-monitor stdio" and that should give you a terminal
> into QEMU. Then in that terminal, run "gdbserver" and it'll open up a gdb
> server on port 1234.

> Then, in another terminal, open gdb and run "target remote :1234" to connect
> to the gdbserver running in qemu.

> At first you'll find that gdb has no fucking idea what's going on. This is
> because it has no symbol data, so you'll need to load your kernel binary
> into it with the "file" command.

> After loading your kernel symbol table, you should be free to roam around
> the inside of your kernel using gdb as normal. If gdb isn't familiar to you,
> I personally really enjoyed Beej's Quick Guide to GDB:
> [http://beej.us/guide/bggdb/](http://beej.us/guide/bggdb/) (pretty much
> everything by

~~~
sitkack
This would make an excellent screencast (not a request)!

