> One of my first thoughts when I saw the Rust project was to make it > runtimeless. Shortly after that was achieved rather trivially with zero.rs. > I don't know if any major improvement can be done there.
As others have said, I don't believe that Rust is currently at the point of being "runtimeless". In addition to what Brian mentioned about not being able to use core-language features easily (vectors, strings, convenient I/O), the story of stacks is also a little sad in runtimeless rust. Currently a "runtimeless" program is still forced to link to librustrt along with our own libmorestack to provide the __morestack function needed by LLVM's segmented stacks. It always seemed a little silly to me that "runtimeless" rust still links to the runtime... Various bits of discussion can be found on https://github.com/mozilla/rust/pull/8955 https://github.com/mozilla/rust/issues/8345 But in summary the story of how stacks are allocated is currently not sufficient for writing something like a kernel module or a kernel itself. I do believe that this is certainly within the realm of possibility, but it certainly needs to be done carefully. I'm not sure if it's too small of a master's project, but I personally consider this to be a fairly substantial undertaking to get right. The various modes discussed in those two issues would be useful to have. This also may not be limited to a runtimeless rust, because the current stack situation is a bit in flux with rust currently. Our segmented stacks are disabled in the new runtime (not implemented yet) and there's some unease about the fixed_stack_segment macro and how it can be more useful. For reference, here's some issues: Runtimeless rust: https://github.com/mozilla/rust/issues/3608 newsched segmented stacks: https://github.com/mozilla/rust/issues/6844 revised stack attributes: https://github.com/mozilla/rust/issues/8822 _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
