Zero.rs: runtime-less Rust programs | Hacker News Reader

Zero.rs: runtime-less Rust programs

github.com

127 pointsdbaupp15 comments

Open articleView on HN

Fun projects of varying ambitiousness that comes to mind:

- Write a Rust garbage collector in Rust, hell, rewrite the Rust runtime in Rust.

- Do a Linux kernel module.

- Or a bootloader.

- Or an entire OS.

This is a great demonstration. It's one thing to know that something can be done, seeing a concrete example is invaluable.

And now I'm kind of itching to write that bootloader.

> - Write a Rust garbage collector in Rust, hell, rewrite the Rust runtime in Rust.

The runtime is currently being rewritten to Rust[1], and the GC-in-Rust is almost complete[2] (as far as I understand it).

[1]: Work in progress: https://github.com/mozilla/rust/tree/incoming/src/libstd/rt

[2]: https://github.com/graydon/rust/tree/gc

We're already doing the first item, as dbuapp mentioned. Actually, we aren't doing it for fun—we're fine with keeping along some C++ for practicality's sake if it's working and we have higher-priority things to do, but the performance of the old scheduler is not where we need it to be, and a rewrite of much of the scheduling code was necessary. Doing it in Rust made sense from a safety and integration standpoint.

Early I/O performance numbers for the new scheduler are quite encouraging. (Nothing to post yet, as we need to do more measurements before we can definitively talk about performance, but you can find numbers in the issue tracker if you're curious.)

Out of curiosity, what are you working on that the performance requirements necessitate rewriting a bunch of the scheduling code?

Great job btw!

Integrating the I/O main loop with the scheduler and work stealing. The new architecture is designed for work stealing, so tasks easily migrate between threads on a demand driven basis to achieve optimum CPU usage. It also allows us to play a bunch of tricks with channel communication that have improved performance of message sends dramatically and pave the way to removing all the locks.

Compulsory link,

http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf

Could this allow for developing a toy kernel in Rust as long as you define those few libc functions (maybe even with e.g. musl[1])?

[1]: http://www.musl-libc.org/

It's tempting to just say "yes". Tool support is not yet good enough. Inline assembly is available. Language constructs allow for deterministic memory allocation patters.

https://github.com/mozilla/rust/pull/5317

Someone may have beaten you to it: https://github.com/charliesome/rustboot

It's not obvious to me you can write to memory at arbitrary memory locations, which is usually a requirement for writing a kernel.

You can:

  unsafe { *(123 as *mut uint) = 4567; }

There is always Assembly as well.

I had demand for that and I'm so happy this got real!!

How does it work?

The Rust compiler doesn't really generate code targeting a runtime in the traditional sense. Rather it generates calls to various "language items" known to the compiler, which are usually defined in the standard library. (Lang items are the Rust equivalent of C++ things like "operator new".)

This is simply a tiny alternate implementation of all the lang items on top of the C library.

Reply on news.ycombinator.com