Writing an OS in Rust
os.phil-opp.com
os.phil-opp.com
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.
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?
There's also https://github.com/thepowersgang/rust_os, which is one of the oldest OS written in Rust, but never gets any press.
How is that possible? An intermediate layer? The kernel is going to be written in rust. You can't just put C code in there and expect it to work. I'm not even sure how you could transcode these drivers into rust considering rust uses a completely different memory model. I suspect a 'real' RustOS will require new drivers to be written from scratch. From a mass adoption perspective, how would have linux worked out if Linus decided to write windows driver shims?
I wonder if its feasible to rewrite things like apache, nginx, php, mysql, gnu utils, etc in Rust but keep the linux kernel as-is. Seems like you'd get the best of both worlds there - a mature and powerful kernel and a Rust userland that's hard to exploit. Most exploited vulnerabilities and stability issues aren't kernel related anyway.
Mozilla's servo project is also interesting. Maybe I don't need a RustOS (yet), but just my internet facing applications in Rust.
Or you could just implement the linux syscalls directly in the kernel, but that seems a bit self-defeating if you want to explore new ideas.
I dunno about performance impact, but I bet it is fairly negligible in the grand scheme of things. In the rump kernel case, these shims really don't do anything, they just pass the call through. Think of it as an API facade. In a hobby OS it might be heavier, if your OS doesn't have a 1:1 mapping of the POSIX/linux syscall to an equivalent.
Also, we virtualize this stuff all the time in cloud environments. Your java app uses the JVM to execute a linux syscall which the kernel translates into a Xen hypercall which Xen uses to call a native driver which talks to the disk, etc etc. You obviously do pay a performance penalty for stacking more and more layers, but it isn't as bad as you'd think (or as good as you hope, take your pick).
But the point is that layering abstractions like this is very much alive and tolerated today in moderately high performance systems :)
Just seems like a good starting point than reworking the entire world.
Also, on the question of "how" you'd do this, I'm not a kernel hacker, but I thought it would be possible to expose FFI, i.e. the shim you talk about, that would allow drivers to be used from something like NetBSD. But you're right that it could be self-defeating in that supporting all of those interfaces might end up constraining the OS in it's attempt to deliver on these features.
On a side note, it seems like it would be nice to expose POSIX FFI hooks to make porting software to a Rust OS easier.
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
Do they work in parallel on same problem/same style/ veru similar codebases? When why not to combine efforts?
Edit: There is also http://www.alexeyshmalko.com/2015/bkernel-a-rust-operating-s...
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.
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.
There are a LOT of decisions that can go into making an OS. The compare/contrast in a few years should be really interesting.
Do you get the debugability automatically? or you have to code to support the debugger?
- printf to serial port
- LEDs attached to GPIOs
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/ (pretty much everything by
I just wrote a guide that should make it straightforward: http://os.phil-opp.com/set-up-gdb.html