2 ms·
Very excited to see this happen! If I may plug the tiny little aspect of this I was involved in, check out https://github.com/rust-lang/rfcs/pull/3271 https://
by Ericson2314 4y ago
Very excited to see this happen!
If I may plug the tiny little aspect of this I was involved in, check out https://github.com/rust-lang/rfcs/pull/3271 https://github.com/rust-lang/rfcs/pull/3271 .
It's a long way off, and it's important to point out the following is not guaranteed to happen so as not to scare off the old hands worried about too much change too quick, but it's interesting to wonder about where this might eventually lead.
Things I would like to see:
1. The above, make sure alloc is good enough for the Kernel for the occasional dynamic memory management one needs to do.
2. Cargo support. Cargo -> {kbuild, Bazel, Nix, ...} should be really slick and easy to do.
3. Out-of-tree code is no longer verboten, because offline support with "Cargo->kbuild" is good and not a source of indeterminism.
4. Drivers and other "periphery code" in Rust increasingly uses enforced minimal interfaces, is reusable in other OS projects.
5. Even Core kernel functionality broken into parts. Think how https://lwn.net/Articles/880175/ https://lwn.net/Articles/880175/ is trying to separate concerns for speed, do that for modularity instead.
6. "Linux" is increasingly not a single multi-million line monolith, but a collection of parts that can be composed together in myriad different ways to build different things. "Composition over configuration" as this supercedes linux's current way of supporting diverse use-cases which is 2^large-number configuration options which have no hope of all being tested or well understood, and few correct-by-construction guarantees over that space.
This is all speculative and multiple decades off, but Linux will probably outlive us unless the nukes go off first so we might as well dream.