Message-ID: <326CC09B-8565-4443-ACC5-045092260677@zytor.com>
Date: Tue, 18 Feb 2025 13:49:00 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        Christoph Hellwig <hch@...radead.org>
CC: rust-for-linux <rust-for-linux@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>, David Airlie <airlied@...il.com>,
        linux-kernel@...r.kernel.org, ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

On February 18, 2025 10:46:29 AM PST, Miguel Ojeda <miguel.ojeda.sandonis@...il.com> wrote:
>On Tue, Feb 18, 2025 at 5:08 PM Christoph Hellwig <hch@...radead.org> wrote:
>>
>> I don't think having a web page in any form is useful.  If you want it
>> to be valid it has to be in the kernel tree and widely agreed on.
>
>Please let me reply with what I said a couple days ago in another thread:
>
>    Very happy to do so if others are happy with it.
>
>    I published it in the website because it is not a document the overall
>    kernel community signed on so far. Again, we do not have that
>    authority as far as I understand.
>
>    The idea was to clarify the main points, and gather consensus. The
>    FOSDEM 2025 keynote quotes were also intended in a similar way:
>
>        https://fosdem.org/2025/events/attachments/fosdem-2025-6507-rust-for-linux/slides/236835/2025-02-0_iwSaMYM.pdf
>
>https://lore.kernel.org/rust-for-linux/CANiq72mFKNWfGmc5J_9apQaJMgRm6M7tvVFG8xK+ZjJY+6d6Vg@mail.gmail.com/
>
>> It also states factually incorrect information.  E.g.
>>
>> "Some subsystems may decide they do not want to have Rust code for the
>> time being, typically for bandwidth reasons. This is fine and expected."
>>
>> while Linus in private said that he absolutely is going to merge Rust
>> code over a maintainers objection.  (He did so in private in case you
>> are looking for a reference).
>
>The document does not claim Linus cannot override maintainers anymore.
>That can happen for anything, as you very well know. But I think
>everyone agrees that it shouldn't come to that -- at least I hope so.
>
>The document just says that subsystems are asked about it, and decide
>whether they want to handle Rust code or not.
>
>For some maintainers, that is the end of the discussion -- and a few
>subsystems have indeed rejected getting involved with Rust so far.
>
>For others, like your case, flexibility is needed, because otherwise
>the entire thing is blocked.
>
>You were in the meeting that the document mentions in the next
>paragraph, so I am not sure why you bring this point up again. I know
>you have raised your concerns about Rust before; and, as we talked in
>private, I understand your reasoning, and I agree with part of it. But
>I still do not understand what you expect us to do -- we still think
>that, today, Rust is worth the tradeoffs for Linux.
>
>If the only option you are offering is dropping Rust completely, that
>is fine and something that a reasonable person could argue, but it is
>not on our plate to decide.
>
>What we hope is that you would accept someone else to take the bulk of
>the work from you, so that you don't have to "deal" with Rust, even if
>that means breaking the Rust side from time to time because you don't
>have time etc. Or perhaps someone to get you up to speed with Rust --
>in your case, I suspect it wouldn't take long.
>
>If there is anything that can be done, please tell us.
>
>> So as of now, as a Linux developer or maintainer you must deal with
>> Rust if you want to or not.
>
>It only affects those that maintain APIs that are needed by a Rust
>user, not every single developer.
>
>For the time being, it is a small subset of the hundreds of
>maintainers Linux has.
>
>Of course, it affects more those maintainers that maintain key
>infrastructure or APIs. Others that already helped us can perhaps can
>tell you their experience and how much the workload has been.
>
>And, of course, over time, if Rust keeps growing, then it means more
>and more developers and maintainers will be affected. It is what it
>is...
>
>> Where Rust code doesn't just mean Rust code [1] - the bindings look
>> nothing like idiomatic Rust code, they are very different kind of beast
>
>I mean, hopefully it is idiomatic unsafe Rust for FFI! :)
>
>Anyway, yes, we have always said the safe abstractions are the hardest
>part of this whole effort, and they are indeed a different kind of
>beast than "normal safe Rust". That is partly why we want to have more
>Rust experts around.
>
>But that is the point of that "beast": we are encoding in the type
>system a lot of things that are not there in C, so that then we can
>write safe Rust code in every user, e.g. drivers. So you should be
>able to write something way closer to userspace, safe, idiomatic Rust
>in the users than what you see in the abstractions.
>
>> So we'll have these bindings creep everywhere like a cancer and are
>> very quickly moving from a software project that allows for and strives
>> for global changes that improve the overall project to increasing
>> compartmentalization [2].  This turns Linux into a project written in
>> multiple languages with no clear guidelines what language is to be used
>> for where [3].  Even outside the bindings a lot of code isn't going to
>> be very idiomatic Rust due to kernel data structures that intrusive and
>> self referencing data structures like the ubiquitous linked lists.
>> Aren't we doing a disservice both to those trying to bring the existing
>> codebase into a better safer space and people doing systems programming
>> in Rust?
>
>We strive for idiomatic Rust for callers/users -- for instance, see
>the examples in our `RBTree` documentation:
>
>    https://rust.docs.kernel.org/kernel/rbtree/struct.RBTree.html
>
>> I'd like to understand what the goal of this Rust "experiment" is:  If
>> we want to fix existing issues with memory safety we need to do that for
>> existing code and find ways to retrofit it.  A lot of work went into that
>> recently and we need much more.  But that also shows how core maintainers
>> are put off by trivial things like checking for integer overflows or
>> compiler enforced synchronization (as in the clang thread sanitizer).
>
>As I replied to you privately in the other thread, I agree we need to
>keep improving all the C code we have, and I support all those kinds
>of efforts (including the overflow checks).
>
>But even if we do all that, the gap with Rust would still be big.
>
>And, yes, if C (or at least GCC/Clang) gives us something close to
>Rust, great (I have supported doing something like that within the C
>committee for as long as I started Rust for Linux).
>
>But even if that happened, we would still need to rework our existing
>code, convince everyone that all this extra stuff is worth it, have
>them learn it, and so on. Sounds familiar... And we wouldn't get the
>other advantages of Rust.
>
>> How are we're going to bridge the gap between a part of the kernel that
>> is not even accepting relatively easy rules for improving safety vs
>> another one that enforces even strong rules.
>
>Well, that was part of the goal of the "experiment": can we actually
>enforce this sort of thing? Is it useful? etc.
>
>And, so far, it looks we can do it, and it is definitely useful, from
>the past experiences of those using the Rust support.
>
>> So I don't think this policy document is very useful.  Right now the
>> rules is Linus can force you whatever he wants (it's his project
>> obviously) and I think he needs to spell that out including the
>> expectations for contributors very clearly.
>
>I can support that.
>
>> For myself I can and do deal with Rust itself fine, I'd love bringing
>> the kernel into a more memory safe world, but dealing with an uncontrolled
>> multi-language codebase is a pretty sure way to get me to spend my
>> spare time on something else.  I've heard a few other folks mumble
>> something similar, but not everyone is quite as outspoken.
>
>I appreciate that you tell us all this in a frank way.
>
>But it is also true that there are kernel maintainers saying publicly
>that they want to proceed with this. Even someone with 20 years of
>experience saying "I don't ever want to go back to C based development
>again". Please see the slides above for the quotes.
>
>We also have a bunch of groups and companies waiting to use Rust.
>
>Cheers,
>Miguel
>
>

I have a few issues with Rust in the kernel: 

1. It seems to be held to a *completely* different and much lower standard than the C code as far as stability. For C code we typically require that it can compile with a 10-year-old version of gcc, but from what I have seen there have been cases where Rust level code required not the latest bleeding edge compiler, not even a release version.

2. Does Rust even support all the targets for Linux? 

3. I still feel that we should consider whether it would make sense to compile the *entire* kernel with a C++ compiler. I know there is a huge amount of hatred against C++, and I agree with a lot of it – *but* I feel that the last few C++ releases (C++14 at a minimum to be specific, with C++17 a strong want) actually resolved what I personally consider to have been the worst problems.

As far as I understand, Rust-style memory safety is being worked on for C++; I don't know if that will require changes to the core language or if it is implementable in library code. 

David Howells did a patch set in 2018 (I believe) to clean up the C code in the kernel so it could be compiled with either C or C++; the patchset wasn't particularly big and mostly mechanical in nature, something that would be impossible with Rust. Even without moving away from the common subset of C and C++ we would immediately gain things like type safe linkage. 

Once again, let me emphasize that I do *not* suggest that the kernel code should use STL, RTTI, virtual functions, closures, or C++ exceptions. However, there are a *lot* of things that we do with really ugly macro code and GNU C extensions today that would be much cleaner – and safer – to implement as templates. I know ... I wrote a lot of it :)

One particular thing that we could do with C++ would be to enforce user pointer safety.

Powered by blists - more mailing lists