[HN Gopher] An RFC that adds support for Rust to the Linux kernel
___________________________________________________________________
An RFC that adds support for Rust to the Linux kernel
Author : steveklabnik
Score : 209 points
Date : 2021-04-14 19:41 UTC (3 hours ago)
(HTM) web link (lkml.org)
(TXT) w3m dump (lkml.org)
| fuzzer37 wrote:
| The one point that stuck out to me is
|
| > At the present time, we require certain nightly features. That
| is, features that are not available in the stable compiler.
| Nevertheless, we aim to remove this restriction within a year by
| either `rustc` landing the features in stable or removing our
| usage of them otherwise.
|
| Using unstable features in something like the Linux kernel just
| seems like a bad idea. Why not wait until Rust is a little more
| matured, and doesn't need to use nightly features?
| steveklabnik wrote:
| They might. There are five things that they're using that they
| can't work around:
|
| One is going to be stable in Rust 1.52.0, the next release of
| Rust. This will happen before the next kernel release, so it
| barely counts. It's also a documentation tooling feature.
|
| One is related to symbol mangling, and so in theory could be
| worked around I'd imagine, but is landing soon enough they
| don't think it's worth it.
|
| The final three are related to each other; two of them look
| like they're being stable pretty soon, and the third, while
| it's less clear on timeline, is one pretty small thing.
|
| So, the answer is basically that the exposure here is pretty
| small. How much that matters is a social question as much as a
| technical one. While "unstable" is a binary designation, within
| it is a spectrum of unstability. "This feature has no path to
| stabilization" to "this will be stable in the next Rust" and
| all things in between. Maybe allowing some unstable things that
| are closer to the latter is acceptable, maybe not.
| Gadiguibou wrote:
| I'm curious about what those specific features are. Could you
| tell me their names? I'd like to go read up on them a bit
| more.
| hmfrh wrote:
| A list is found here[1].
|
| [1]: https://github.com/Rust-for-Linux/linux/issues/2
| imjasonmiller wrote:
| See https://github.com/Rust-for-Linux/linux/issues/2
| jeffbee wrote:
| It will be interesting if this gains traction, while C++ in the
| kernel never did. Many, many bugs in the Linux kernel would have
| been prevented with C++ (the entire class of `goto cleanup;`
| bugs, for example).
| joseluisq wrote:
| Maybe because of this?
|
| > I think that the standard Rust API may simply not be
| acceptable inside the kernel, if it has similar behavior to the
| (completely broken) C++ "new" operator.
|
| https://lkml.org/lkml/2021/4/14/1131
|
| I'm not a C++ dev BTW, so this could need more details by
| someone with background for it.
| jeffbee wrote:
| Eh, that's just Linus continuing to demonstrate how little he
| knows about C++.
| yjftsjthsd-h wrote:
| How would having (some of) Linux written in C++ prevent goto
| bugs?
| jeffbee wrote:
| The goto bugs are often failures to release locks in the
| error paths, or failure to free some other resource, or
| sometimes double frees. C++ programs that use RAII locks
| rarely have these types of issues.
|
| Many casual users never notice these bugs, but if you put a
| Linux box under enough pressure that some kmalloc fails, it
| will fall to pieces because the error paths are full of bugs
| and little-exercised. C has probably the worst error-path
| control flow of any of the high-level languages.
| matvore wrote:
| Can you give an example?
|
| The alternatives to goto cleanup; have drawbacks too - like
| being less readable (cleanup code is before the main function
| body or destructors do things implicitly).
| dochtman wrote:
| The list of unstable features they want to use is interesting:
|
| https://github.com/Rust-for-Linux/linux/issues/2
| ndesaulniers wrote:
| Lore link:
| https://lore.kernel.org/lkml/20210414184604.23473-1-ojeda@ke...
| [deleted]
| cbmuser wrote:
| Luckily, the gccrs developemt work is now backed by a company who
| is paying the main developer:
|
| > https://rust-gcc.github.io/
|
| Having Rust support directly built into GCC means Rust code in
| kernel will not limit portability and no additional toolchain
| will be needed.
| habitue wrote:
| > The project is still in an early phase with the goal to
| compile the offical Rust test suite. There are no immediate
| plans for a borrow checker as this is not required to compile
| rust code and is the last pass in the RustC compiler. Even with
| a full-time developer.
|
| This is essentially a reimplementation of rustc. I'm not going
| to say "don't boil the ocean" but it will likely be a while
| before this is at feature parity with the main compiler.
|
| There is a project to use gcc as a backend for rustc, which
| might be a more tractable option to removing the llvm
| dependency in the short term:
|
| https://github.com/antoyo/rustc_codegen_gcc
| CyberRabbi wrote:
| Does this RFC include all the requisite "safe" interfaces to
| enable writing a fully featured driver in Rust? If not, is it
| theoretically possible to create those safe interfaces within
| Linux's API driver infrastructure? Or will some unsafe API usage
| always be necessary in Rust?
|
| I remember there was an issue writing a rust-safe wayland
| compositor on top of wlroots because wlroot's ownership model was
| simply not able to be cast in terms of interfaces that rust was
| able to prove were safe. [1] Is this not an issue in Linux?
|
| [1] http://way-cooler.org/blog/2019/04/29/rewriting-way-
| cooler-i...
| timidger wrote:
| I haven't done any Linux work (except for some stuff with
| device tree that I've mostly forgotten), but that post I made
| about Way Cooler may not be generalizable to all C APIs. It's
| also possible that I simply was not creative enough with my API
| design - since that blog post a few people have reached out
| with alternative designs that avoid some of the issues I ran
| into. I haven't dug into them however, since I'm no longer
| interested in working on Way Cooler.
|
| It's not so much "Rust can't represent this ownership model" as
| "this ownership model is basically orthogonal to Rust's so you
| have to put much more effort in to write idiomatic Rust code
| compared to writing it in C". I would love for someone to come
| along and prove me wrong with a better wlroots wrapper.
|
| Also, Wayland composites are much, much simpler than the Linux
| kernel, so that train of thought doesn't necessarily scale out.
| steveklabnik wrote:
| From the link:
|
| "The intention is to make these as safe as possible so that
| modules written in Rust require the smallest amount of `unsafe`
| code possible."
|
| When writing a kernel, some unsafe somewhere is always
| required, on some level.
| CyberRabbi wrote:
| Yes I saw that but it wasn't clear on whether it was possible
| or if there was a clear plan to make it 100% safe.
|
| You're saying some unsafe code is always necessary, why
| should that be the case? I think the big issue with wlroots
| was its callback-based API which is common with Linux-
| internal APIs as well. On a theoretical basis I'm not sure
| what this means for Rust. Is it simply not possible in the
| abstract to cast these types of APIs in a form that can be
| statically proven to be safe? Or is this a deficiency in the
| current design of Rust? Are all "callback-based" APIs
| inherently unsafe in Rust? Is it always theoretically
| possible to recast those APIs in a form that Rust can prove
| is safe? I would just want to understand exactly why it's
| possible to write 100% safe Rust programs in user space and
| not in Linux kernel space.
|
| These are the types of questions I would ask when evaluating
| whether or not it's worth investing in and using Rust for my
| Linux driver.
| swiley wrote:
| Rust seems neat but one thing I've always liked about Linux is
| how few dependencies it needs to compile. The current rust
| compiler is not small and depends on LLVM which is not great.
| amelius wrote:
| Why is LLVM a problem?
| erik_seaberg wrote:
| According to
| https://www.kernel.org/doc/html/latest/kbuild/llvm.html
|
| > LLVM does not target all of the architectures that Linux
| supports and just because a target is supported in LLVM does
| not mean that the kernel will build or work without any
| issues.
| cbmuser wrote:
| This is why gccrs development is now backed by a company:
|
| > https://rust-gcc.github.io/
|
| With gccrs, the portability issues of rustc will go away and no
| extra toolchain will be needed for the Rust code in the kernel
| either.
| bjourne wrote:
| Might be useful to recall that Rust's 1.0 release was in 2015. It
| may be a little premature to reimplement parts of Linux in such a
| young language... Rust may be a fad and may not catch on. I have
| used it a bit and I don't think it offers many significant
| benefits over C++.
|
| (The Rust brigade is out in force I see :))
| asimpletune wrote:
| > We decided to go with Rust's idiomatic style, i.e. keeping
| `rustfmt` defaults. For instance, this means 4 spaces are used
| for indentation, rather than a tab. We are happy to change that
| if needed -- we think what is important is keeping the formatting
| automated.
|
| Hahaha, preemptive offering compromise on tabs vs spaces warms my
| soul, good stuff.
| steveklabnik wrote:
| Linus's initial reaction: https://lkml.org/lkml/2021/4/14/1099
|
| I am pleased that these are all addressable things. We'll see!
| xiphias2 wrote:
| They are not just addressable, but actually make Rust itself a
| better systems programming language.
| steveklabnik wrote:
| Yes, I specifically would really like to see what Josh is
| talking about here happen:
| https://lore.kernel.org/lkml/YHdSATy9am21Tj4Z@localhost/
|
| It's kind of a funny space; right now Rust handily gives you
| "no allocations" (this is where I live) or "infallible +
| fallible allocations" (this is alloc/std by default) but not
| "only fallible allocations". This sort of thing is basically
| filling out the quadrant of options.
| hathawsh wrote:
| The most impressive part is that it's actually conceivable
| to implement such deep changes without a major version bump
| in Rust. (I hope so anyway!)
| steveklabnik wrote:
| Yup, it is. If this plan linked above were to be
| implemented, what would happen is that you would get the
| same behaviors by default, but with a new setting, you'd
| get some APIs removed. That's backwards compatible.
| tetha wrote:
| I was thinking that when reading the exchanges. This is a
| really good interaction. Linus and the kernel have strong
| requirements for good reasons, and the rust teams are trying
| to address them in useful ways.
|
| Rust in the kernel is not a simple thing, but I think both
| rust and the kernel will benefit.
| joseluisq wrote:
| Yep, BTW looking forward https://lkml.org/lkml/2021/4/14/1105
| those kind of 'real piece of code' that pleases Linus :)
| caslon wrote:
| It's unfortunate that this might happen. Kernel compilation
| times were starting to become so reasonable!
| pedrocr wrote:
| Even for normal user space code having a way to detect panic at
| compile time and abort compilation would be great. Ideally
| together with a way to wrap functions that do panic by catching
| it and throwing an error instead so the panic infrastructure
| can still be used. I've sketched that out on HN the other day:
|
| https://news.ycombinator.com/item?id=26191644
| dbrgn wrote:
| There's a Rust RFC and Linus doesn't hate it. Great news!
| joseluisq wrote:
| Yeah! Even he kind of appreciates one of my favorite Rust
| features.
|
| > So "Result<T, E>" is basically the way to go, and if the
| standard Rust library alloc() model is based on "panic!" then
| that kind of model must simply not be used in the kernel.
|
| https://lkml.org/lkml/2021/4/14/1131
| easton wrote:
| What does NAK mean?
| momothereal wrote:
| The opposite of ACK (Acknowledged) in many protocols.
| Basically Rejected.
| diamondo25 wrote:
| Usually Not Acknowledged.
| gnull wrote:
| "Not Acknowledged", I believe [1].
|
| [1]: https://www.kernel.org/doc/html/v4.15/process/stable-
| kernel-...
| [deleted]
| nynx wrote:
| It's already _kind of_ possible to statically prevent all
| panics: https://crates.io/crates/no-panics-whatsoever.
|
| It's pretty hacky, but it works on no_std.
| yazaddaruvala wrote:
| Do you think a more ergonomic `#[no_panic]`[0] would require
| Rust wait for an entire effect system, or be valuable enough to
| add to the compiler as a one-off?
|
| [0] https://github.com/dtolnay/no-panic
| steveklabnik wrote:
| I am not sure.
| yagizdegirmenci wrote:
| Linus addresses the RFC 2116[1] of Rust which aims to add
| support for fallible allocations to the standard collection
| APIs.
|
| This RFC is accepted and implemented. See the Josh's answer[2].
|
| [1]: https://github.com/rust-
| lang/rfcs/blob/master/text/2116-allo... [2]:
| https://lore.kernel.org/lkml/YHdSATy9am21Tj4Z@localhost/
| JoshTriplett wrote:
| RFC 2116 addresses part of the issue. The other part of the
| problem would be to support disabling the non-fallible APIs
| at compile time.
|
| Also, RFC 2116 assumes that it's sufficient to provide (for
| instance) Vec::try_reserve, and require callers to always
| call that before calling anything that might expand the Vec.
| That wouldn't eliminate the runtime panics. It might be
| necessary to go a step further, and actually provide fallible
| versions of individual Vec methods. (Or there may be other
| potential solutions.)
| tomphoolery wrote:
| Would this make Linux the first *NIX-based OS that is written in
| a language other than C? At least, with high usage...
| yjftsjthsd-h wrote:
| If you _don 't_ qualify it with "high usage", redox is that.
| There's also a semantic question; is Linux with some drivers
| done in Rust really an OS written in a language other than C?
| It's not like they intend to replace all the existing C with
| Rust.
| _joel wrote:
| I'm not sure but even in the short to mid term I can't see it
| replacing swathes of code already written in C. Drivers and
| such, maybe
| isItStill wrote:
| Replace enough of the code, is it still Linux?
|
| Perl 6 or bust!
|
| https://en.m.wikipedia.org/wiki/Ship_of_Theseus
| jasonhansel wrote:
| This is as much good news for Linux as it is for Rust. In the
| long run, there is a nontrivial risk that Linux could be replaced
| by an OS written in a safer language. Moving to a safer language
| within Linux is likely to ensure Linux's long-term survival in
| smartphones and servers alike.
| alrs wrote:
| The good news is that Rust is going to need to get serious
| about first-tier support for all architectures supported by the
| Linux kernel if this is to go anywhere.
| attractivechaos wrote:
| And LLVM, to that matter. There is gcc-rust but not sure when
| it will become mature enough.
| nynx wrote:
| I'm not sure "risk" is the right word for it.
| jasonhansel wrote:
| <rant>
|
| I say "risk" because any such OS would probably be available
| under a license more permissive than the GPL. The result
| would almost certainly be that large parts of the OS would
| become proprietary (NVIDIA has already tried this with
| Linux's limited module support).
|
| Of course, moving to Rust is also a risk in this respect,
| since the LLVM toolchain is BSD-licensed, but hopefully Rust
| support will be added to GCC in the not-too-distant future.
| secondcoming wrote:
| Can someone expand on the debate about alloc()?
|
| Does Rust always panic on allocation failure?
| steveklabnik wrote:
| > Does Rust always panic on allocation failure?
|
| No. See more below.
|
| > Can someone expand on the debate about alloc()?
|
| So the question is the one you asked above, but also, more
| generally, "is it possible to statically disallow panic on
| OOM?" and related things.
|
| Rust the language itself, that is, the language + the core
| library, doesn't know anything about allocations at all. There
| are none. Concept doesn't exist. So that's fine.
|
| Rust also provides the "alloc" library, which can be layered on
| top of core. This gives you standard APIs for allocation. They
| also contain several data structures that use allocation
| internally. These data structures have APIs that may panic on
| OOM.
|
| So, Linus saw those things, and naturally asked questions about
| how required they are. The answer is "not required, but it's
| work to get rid of them, there's a few options, and we didn't
| want to do that work until we got a higher-level gut check from
| you."
|
| Does that all make sense?
| Gadiguibou wrote:
| Thank you for taking the time to explain this. I'm familiar
| with Rust, but didn't know what he was referring to.
| asimpletune wrote:
| Great explanation, thanks
| dochtman wrote:
| The list of unstable features they want to use is interesting:
|
| https://github.com/Rust-for-Linux/linux/issues/2
| joseluisq wrote:
| Latest Miguel Ojeda reply to Linus concerns
|
| https://lkml.org/lkml/2021/4/14/1130
___________________________________________________________________
(page generated 2021-04-14 23:00 UTC)