
Writing an OS in Rust: Handling Exceptions - adamnemecek
https://os.phil-opp.com/handling-exceptions.html
======
bluejekyll
I wish I had more spare time to help work on something like this. I've been
reading all of these posts since the beginning, and they are all so excellent.
I knew a lot of these things abstractly, but this explains it all in such
solid detail, it's awesome. Thank you!

Now a question for people in the know about micro-kernel architectures. One
thing often claimed is that the message passing is too expensive, causing
essentially double the work per system call.

After reading this, I started wondering, and now want to read more about it:
is it possible to use page faults and a handler to effectively build a message
passing setup in the microkernel? Essentially using the pagefault as the
mechanism to switch stacks from one kernel-service to another? Is this novel,
stupid, or even faster than existing mechanisms?

Obviously I need to go read how L4 and others do this. What's great about
posts like this is that it makes me want to go learn about it...

~~~
adamnemecek
> Obviously I need to go read how L4 and others do this.

The L4 guy wrote a paper on it.
[https://www.cs.nyu.edu/~mwalfish/classes/15fa/ref/liedtke93i...](https://www.cs.nyu.edu/~mwalfish/classes/15fa/ref/liedtke93improving.pdf)

I think I've been intrigued by the same idea, I believe that Rust enables you
to build a reactive OS which would simplify a lot of programming. Given that
interrupts are basically events, it's a match made in heaven.

If someone wants to talk about this (by "this" I guess I mean the new OS
architectures that are now possible due to Rust) more, shoot me an email (it's
in my profile).

~~~
mastax
You may be interested in these projects:

[https://github.com/ryanra/RustOS](https://github.com/ryanra/RustOS)

RustOS is hobby OS project that's pretty bare bones, but has similar ideas to
what you've mentioned. It's essentially a port of the Rust standard library to
bare metal, relying on the safety of the language rather than hardware
features. It's sort-of a unikernel in implementation if not intention.

[https://github.com/helena-project/tock](https://github.com/helena-
project/tock)

Tock is an interesting academic project to create an embedded OS. It still
uses more traditional hardware protection for user processes, since these can
be written in any language. The kernel, however, is composed of cooperatively-
scheduled components called capsules, which rely on the language for isolation
and don't have the overhead associated with real processes. See this doc for
more details:
[https://www.tockos.org/documentation/design/](https://www.tockos.org/documentation/design/)

~~~
adamnemecek
Both of those look really dope. How did you learn about them?

~~~
kibwen
reddit.com/r/rust is a useful resource for keeping abreast of Rust-related
happenings.

For other OS stuff in Rust, see Redox (a microkernel) and Robigalia (Rust on
seL4).

~~~
adamnemecek
I think that the thing I'm most interested in is what new architectures does
Rust allow for.

Redox is cool but Unix has outlived it's usefulness at this point. Also. the
Unix philosophy is the very anti-thesis of what I think is the Rust
philosophy. I can imagine that a Rust port of QNX could be a big deal tho (QNX
is/was only like 500KLOC of C, which could be like 100KLOC of Rust).

But I think that we need mode advanced systems, e.g. don't need as much
virtual memory protection because that's handled by the language. There's
actually quite a few things in the current OSs that seem to be pure
anachronisms.

~~~
bluejekyll
> don't need as much virtual memory protection because that's handled by the
> language.

This is true at compile time. But what does it do for you at runtime when bad
actors will be trying to break any and all assumptions? The guarantees in the
kernel need to be vigilant against attackers, so while the kernel itself might
be simpler, the boundary with processes still needs a lot of constraints at
runtime.

~~~
krzat
I think the assumption here is that OS would only allow binaries built from
safe rust code.

~~~
bluejekyll
Sure, but I don't know how you'd still guard against runtime issues. I'm not
even sure you could require user space only safe code.

------
Animats
_" x86-interrupt calling convention is such a calling convention"_

Language support for interrupts. That's convenient. Usually it takes assembly
language glue code to save and restore CPU state.

------
andreiw
One thing that stands out over almost every other similar article is that
there are alternative calling conventions available. That is - awesome. Not
sure if this is something easily defined in a crate, or if it is intrinsic,
but it is very liberating to know that you don't need to craft exception entry
/ exit code unless you really want to. That makes OS-level tinkering much much
more approachable.

------
phil-opp
Why is this marked as dupe? Yes, there were already posts about exception
handling ( "Catching Exceptions" [1]), "Better Exception Messages" [2], and
"Returning from Exceptions" [3]). These posts used naked functions and a lot
of inline assembly for exception handling.

This is a new post that I published today. It uses the new `x86-interrupt`
calling convention [4] instead of naked functions, which is much easier.

[1]: [https://os.phil-opp.com/catching-exceptions.html](https://os.phil-
opp.com/catching-exceptions.html)

[2]: [https://os.phil-opp.com/better-exception-messages.html](https://os.phil-
opp.com/better-exception-messages.html)

[3]: [https://os.phil-opp.com/returning-from-exceptions.html](https://os.phil-
opp.com/returning-from-exceptions.html)

[4]: [https://github.com/rust-lang/rust/pull/39832](https://github.com/rust-
lang/rust/pull/39832)

~~~
dang
Sorry, my mistake.

~~~
phil-opp
No worries! Thanks for correcting it.

------
Sir_Cmpwn
Previously: [https://hn.algolia.com/?q=phil-
opp.com](https://hn.algolia.com/?q=phil-opp.com)

Just about every page of this tutorial has frontpaged on HN. I guess people
really, really, _really_ want more kernels written in Rust!

~~~
milesrout
No surprise that you get responses from the Rust Defence League.

They downvote any criticisms of Rust here and on reddit, and upvote anything
that mentions it in a positive light. They rush to its defence everywhere.

I seriously reckon that steveklabnik and pcwalton must have a bot watching HN
and reddit for mentions of Rust so they can immediately rush to its defence
every time it comes up.

It's a pity because _I actually think the language has potential_ , but it's
not going to be successful if they're incapable of taking any critique on
board. And it's _not_ ready, it's _not_ mature. They have to accept that.

~~~
wtetzner
> And it's not ready, it's not mature. They have to accept that.

Do you have anything specific in mind that makes it "not ready"? And when you
say it's not ready, what isn't it ready for?

