Hacker News new | past | comments | ask | show | jobs | submit login
Rustboot: a 32 bit kernel written in Rust (github.com/charliesome)
195 points by steveklabnik on May 26, 2013 | hide | past | favorite | 54 comments

I saw zero.rs and said, "Hey, I know! I'm going to make a kernel!" Then after showering... came back and saw this.

Well, in any case, great work! (Perhaps I'll use yours as a starting point.)

EDIT: One question. When I try to compile it, rustc gives me these errors:

    error: no item found for `modulo`
    error: no item found for `durable`
    error: aborting due to 2 previous errors
If I had to guess, it would be due to the fact that I'm trying to compile it on OS X but have i386-intel-linux set as the target, but your screenshot shows (at least it being emulated) on OS X. Did you have to build a special cross compiler version of rustc?

Please don't let this stop you writing a kernel, I'm sure we'd all love to see what you do!

Make sure you're using git/incoming, that's the latest and most stable version usually.

I use ELF as the object file format, but all the development was done on OS X.

Maybe try updating your version of Rust. I had trouble using zero.rs on 0.6, but the latest from Git works well.

Ah, that would explain it -- I'm trying it with 0.6. Building master now, have a feeling that it'll be a while though.

Beware, "the latest" usually means incoming, not master. That said, I'm not sure which is actually meant above.

I had the same problem (I'm on ArchLinux). I fixed it as follows: https://github.com/FrozenCow/rustboot/commit/ec46219d50f4403...

No idea whether this is actually correct, but it does run in qemu. It doesn't however boot on my laptop from a USB drive though... not sure how actual hardware is different from qemu.

It might be something to do with me not enabling the A20 line, I'm not sure if QEMU starts with it disabled or not.

If anybody is looking for something to do with this, consider writing a KVM-like virtual machine host which is barebones enough to boot from coreboot.

I've dreamed of a checkpointed VM which could be used to press a key and fork the running system, or instantly reboot to a usable state when a fault occured, but was small enough to fit in a flash ROM and boot in milliseconds.

The last attempt was linux+QEMU and was to large for most boards supported by coreboot.

Yup, this kind of thing is one of the reasons I like exokernels so much.

What about as a UEFI image? I've never had a board that was supported by CoreBoot.

This is great, but I'm confused. Not that long ago, I remember reading that it was explicitly not a goal of Rust to be able to write an OS kernel in it. Is this done in spite of Rust not being designed/suited for it?

Originally we didn't think we could be that low-level and provide all the safety guarantees we wanted, but eventually as the language design matured we realized we could.

I'm not sure that I've ever heard that as an implicit goal, but a 'runtime-less Rust' hasn't existed yet. Now, you can't access arbitrary memory without an unsafe block, that may be what you're thinking of.

Recently, zero.rs was released, which allows you to write some Rust programs without the runtime. This is because Rust basically expects certain functions to exist, so they have to be defined somewhere. That said, things like 'a GC' aren't implementd, they just throw an error. Please see: https://news.ycombinator.com/item?id=5771173

This is just one step further in demonstrating that these things work.

A link to the HN thread on zero.rs


I'm sure they (the Rust developers) don't have any particular interest in writing an OS kernel using Rust, but that doesn't mean someone else can't give it a try.

Of course it's hard to pass off these ~200 lines of code as an attempt at writing an OS kernel, but it could be a spark, everything starts somewhere.

> I remember reading that it was explicitly not a goal of Rust to be able to write an OS kernel in it.

It's not a goal of rust, but that doesn't mean rust can't be used for it (and the ability to run without a runtime if desired — at the loss of functionalities for which a runtime support is necessary — has been a goal of the project for as long as I've known about it)

Great to see new Rust news every day.

At first I was most interested in Go: But now it seems that Rust is much more close to the metal than Go is, which I find more interesting.

>It paints the screen bright red and then hangs.

Well, it's a start, I guess. :) (The project is literally only half an hour old.)

> (The project is literally only half an hour old.)

That's one of the funny things about starting your own operating system; it's not some sort of herculean task. Especially once you've done it once or twice.

While you're right that this isn't particularly feature-rich at this point, it does get the annoying bits out of the way. It's a starting point that anyone doing this task would have to do, and do in the same way.

It's also a proof of concept that this kind of thing does actually work; see the other thread on zero.rs where people were speculating if this is possible. Now we know.

Just add some weird error lines and you have a Red Screen Of Death (RSOD)[1], certainly a good beginning :)

[1] http://en.wikipedia.org/wiki/Red_Screen_of_Death

Not necessary. Most hobby OS projects stop at that stage (including mine, many many years ago...).

Sounds better than Vista!

Obviously didn't get the joke: http://xkcd.com/528/

Or didn't consider the joke appropriate for Hacker News, I guess.

Wow, if people like this, then maybe I should post my tiny 32-bit kernel in C++ somewhere. It has a physical, virtual, and kernel memory manager and support for text-mode I/O. And you can use pretty much anything C++ (even Boost) that doesn't rely on exception handling...

I'd like to see it if you don't mind.

Hmm... since I'm not sure I want to share the code yet, here's a class diagram instead that should still give you an idea what state it's currently in:


The Process class is just a dummy at the moment, it doesn't do anything.

Something similar I did with Clojure:


It's really impressive what people have done with rust. I don't know how they do it because when I write short rust programs I get internal compiler errors.

You should open up issues for those: https://github.com/mozilla/rust/issues

There's no reason for an internal compiler error, especially in a language with safety as its focus.

Have done. Here are the ones I found in 300 loc.

https://github.com/mozilla/rust/issues/6699 https://github.com/mozilla/rust/issues/6698

Don't get me wrong. I'm super excited to learn rust once it stabilizes. But right now I don't spend enough time on fun programming to deal with a language that has this many errors.

Great! Thank you. I've been mostly sticking to documentation myself, but you can't fix what you don't know...

I find this a very exciting project. Rust is always in my peripheral vision. To see a language operating at such a high level able to get down so low is very compelling.

I am confused: if it's a kernel, why do we have the mac user interface? Is this the screenshot from a VM or am I missing something else?

Yes, it's a VM. Note the title, "QEMU".

I guess this is kind of a factious question to ask, but why 32 bit and not 64 bit?

Are there any technical reasons for this?

32 bit is waaaaaaay easier to write.

This is cool!

One request, Can you detail out the steps, for noobies to be able to re-produce this effort? Thanks!

Reproduce as in 'build a tiny kernel in something' or reproduce as in 'build and run this example?'

If it's the first, OSDev has a great community, and some decent tutorials: http://wiki.osdev.org/Bare_Bones

If it's the second, the answer is 'have edge Rust installed, have qemu installed, then run `make`.'

I wrote an example/tutorial (targeted in C though, not rust) a few years back which may have some of what you're looking for:


Wow, cool! Great job :)

That isn't a kernel

Don´t know why this was downvoted, you hit the nail on its head. The fact that it runs directly on hardware doesn't make it a kernel, it doesn't provide any abstractions for applications to run unmodified without specific hardware provisions.

Exokernels provide no abstractions, just a few safety guarantees. So you could argue that this is just an unsafe exokernel. ;)

That said, "is it really a kernel as per Wikipedia" is not particularly interesting. It's a damn cool hack that could be the starting point for something interesting and useful, that's all I care about.

Exokernels still provide abstractions that allow multiple userspace processes to interact with the hardware. The abstractions are just closer to the underlying hardware, e.g. disk blocks instead of files.

That's right, don't let their pedantry get you down. It was an interesting post, thank you for sharing it.

I was just a little disappointed Steve. Interesting post for sure. Would be interested in seeing part 2 ;)

My friends have been working on an exokernel in D for years, so that's been our go-to for this kind of thing. It's only like 10 kloc, maybe we should port it for fun...


Now, it's not a _useful_ kernel, but it is one.

In fact it does one thing and does it well. It's an exemplar of the UNIX philosophy! ;)

It only supports itself, so not a kernel. See: http://en.wikipedia.org/wiki/Kernel_(computing)

I disagree. It ships with a single built-in application which turns the screen red. Someone can take the codebase and replace the application with a different one.

I seem to remember some old 5 1/4 inch disks that contained both an OS and an app. That's approximately what this is in its current state.

That isn't a useful comment

Bringing attention to misinformation is useful

Telling someone to stop being an asshole is useful

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact