5 ms·
Zero.rs: runtime-less Rust programs
- devinus 13y agoCould 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/ http://www.musl-libc.org/
- dietrichepp 13y agoIt'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 https://github.com/mozilla/rust/pull/5317
- richardwhiuk 13y agoIt's not obvious to me you can write to memory at arbitrary memory locations, which is usually a requirement for writing a kernel.
- kibwen 13y agoSomeone may have beaten you to it: https://github.com/charliesome/rustboot https://github.com/charliesome/rustboot
- kryptiskt 13y agoFun 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.
- dbaupp 13y ago> - 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 https://github.com/mozilla/rust/tree/incoming/src/libstd/rt [2]: https://github.com/graydon/rust/tree/gc https://github.com/graydon/rust/tree/gc
- pjmlp 13y agoCompulsory link, http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf
- pcwalton 13y agoWe'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.)
- pvnick 13y agoOut of curiosity, what are you working on that the performance requirements necessitate rewriting a bunch of the scheduling code? Great job btw!
- pepijndevos 13y agoHow does it work?
- pcwalton 13y agoThe 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.
- X4 13y agoI had demand for that and I'm so happy this got real!!