Message-ID: <757c92b484bb13172426644b5b5193bca391d14e.camel@gmail.com>
Date: Thu, 20 Feb 2025 15:33:51 +0300
From: vpotach@...il.com
To: hpa@...or.com
Cc: airlied@...il.com, gregkh@...uxfoundation.org, hch@...radead.org, 
	ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org, 
	miguel.ojeda.sandonis@...il.com, rust-for-linux@...r.kernel.org, 
	torvalds@...ux-foundation.org
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.

why there is can't simplify kernel development by c++ without use std
and others overhead features. C++ have ideal C binding, why not

Powered by blists - more mailing lists