Rust 4 Linux

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
rust-for-linux <rust-for-linux@vger.kernel.org>,
Greg KH <gregkh@linuxfoundation.org>,
David Airlie <airlied@gmail.com>,
linux-kernel@vger.kernel.org, ksummit@lists.linux.dev
Subject: Re: Rust kernel policy
Date: Thu, 20 Feb 2025 16:39:58 -0800 [thread overview]
Message-ID: <CAHk-=wgLbz1Bm8QhmJ4dJGSmTuV5w_R0Gwvg5kHrYr4Ko9dUHQ@mai l.gmail.com> (raw)
In-Reply-To: <Z7bO1jT2onZFZwgH@infradead.org>

On Wed, 19 Feb 2025 at 22:42, Christoph Hellwig <hch@infradead.org> wrote:
>
> The document claims no subsystem is forced to take Rust. That's proven
> to be wrong by Linus. And while you might not have known that when
> writing the document, you absolutely did when posting it to the list.

I was hopeful, and I've tried to just see if this long thread results
in anything constructive, but this seems to be going backwards (or at
least not forwards).

The fact is, the pull request you objected to DID NOT TOUCH THE DMA
LAYER AT ALL.

It was literally just another user of it, in a completely separate
subdirectory, that didn't change the code you maintain in _any_ way,
shape, or form.

I find it distressing that you are complaining about new users of your
code, and then you keep bringing up these kinds of complete garbage
arguments.

Honestly, what you have been doing is basically saying "as a DMA
maintainer I control what the DMA code is used for".

And that is not how *any* of this works.

What's next? Saying that particular drivers can't do DMA, because you
don't like that device, and as a DMA maintainer you control who can
use the DMA code?

That's _literally_ exactly what you are trying to do with the Rust code.

You are saying that you disagree with Rust - which is fine, nobody has
ever required you to write or read Rust code.

But then you take that stance to mean that the Rust code cannot even
use or interface to code you maintain.

So let me be very clear: if you as a maintainer feel that you control
who or what can use your code, YOU ARE WRONG.

I respect you technically, and I like working with you.

And no, I am not looking for yes-men, and I like it when you call me
out on my bullshit. I say some stupid things at times, there needs to
be people who just stand up to me and tell me I'm full of shit.

But now I'm calling you out on *YOURS*.

So this email is not about some "Rust policy". This email is about a
much bigger issue: as a maintainer you are in charge of your code,
sure - but you are not in charge of who uses the end result and how.

You don't have to like Rust. You don't have to care about it. That's
been made clear pretty much from the very beginning, that nobody is
forced to suddenly have to learn a new language, and that people who
want to work purely on the C side can very much continue to do so.

So to get back to the very core of your statement:

"The document claims no subsystem is forced to take Rust"

that is very much true.

You are not forced to take any Rust code, or care about any Rust code
in the DMA code. You can ignore it.

But "ignore the Rust side" automatically also means that you don't
have any *say* on the Rust side.

You can't have it both ways. You can't say "I want to have nothing to
do with Rust", and then in the very next sentence say "And that means
that the Rust code that I will ignore cannot use the C interfaces I
maintain".

Maintainers who *want* to be involved in the Rust side can be involved
in it, and by being involved with it, they will have some say in what
the Rust bindings look like. They basically become the maintainers of
the Rust interfaces too.

But maintainers who are taking the "I don't want to deal with Rust"
option also then basically will obviously not have to bother with the
Rust bindings - but as a result they also won't have any say on what
goes on on the Rust side.

So when you change the C interfaces, the Rust people will have to deal
with the fallout, and will have to fix the Rust bindings. That's kind
of the promise here: there's that "wall of protection" around C
developers that don't want to deal with Rust issues in the promise
that they don't *have* to deal with Rust.

But that "wall of protection" basically goes both ways. If you don't
want to deal with the Rust code, you get no *say* on the Rust code.

Put another way: the "nobody is forced to deal with Rust" does not
imply "everybody is allowed to veto any Rust code".

See?

And no, I don't actually think it needs to be all that
black-and-white. I've stated the above in very black-and-white terms
("becoming a maintainer of the Rust bindings too" vs "don't want to
deal with Rust at all"), but in many cases I suspect it will be a much
less harsh of a line, where a subsystem maintainer may be *aware* of
the Rust bindings, and willing to work with the Rust side, but perhaps
not hugely actively involved.

So it really doesn't have to be an "all or nothing" situation.

Linus

Sedan är ju frågan vad som egentligen stoppar kärnan från att vidareutvecklas om stannar kvar vid C? Påståendet att det skulle vara bättre att skriva kärnan i Rust istället för C handlar inte om att kärnan skulle bli funktionellt bättre om man skrev den i det ena språket eller det andra, utan om att man kommer köra fast och inte lyckas vidareutveckla kärnan om man inte byter till Rust. Men är det verkligen sant? Det enda sättet avgöra frågan är att utveckla två olika kärnor, den ena skriven i Rust och den andra skriven i C, och så får framtiden utvisa vilken som kommer att nå längst. Men det man gör nu är att skapa en hybrid som är svårare att utveckla än de renodlade alternativen, och vart skall det leda annat än att man blir omkörd av någon annan?

Jo det är ett mycket starkt skäl att Rust är mer säkert. Det blir i praktiken funktionellt och ekonomiskt bättre - mer effektivt.

Ja varför inte? Jag gissar att Torvalds bara vill ha 1 kärna? Blir dubbelt arbete för Torvalds i deras utvecklingsmodell att ha två separata spår.

Mixade kodbaser är inget nytt. Fråga en fullstack webdev om alla deras jävla mikrotjänster som skrivs i samma team. Det är bökigt, men det går. Kan en javascript-apa hålla reda på sin overengineerade stack så kan en Kernel-utvecklare hålla reda på C och Rust. Dessutom har Rust-folket sagt till C-folket: ”ni behöver inte bry er om Rust-koden, ni kör på och om något Rust-relaterat går sönder så är det på oss att det fixas, fokusera på C ni.”

As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years (well hopefully all of them end up in the stable trees, we do miss some at times when maintainers/developers forget to mark them as bugfixes), and who sees EVERY kernel CVE issued, I think I can speak on this topic.

The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)

I'm all for moving our C codebase toward making these types of problems impossible to hit, the work that Kees and Gustavo and others are doing here is wonderful and totally needed, we have 30 million lines of C code that isn't going anywhere any year soon. That's a worthy effort and is not going to stop and should not stop no matter what.

But for new code / drivers, writing them in rust where these types of bugs just can't happen (or happen much much less) is a win for all of us, why wouldn't we do this? C++ isn't going to give us any of that any decade soon, and the C++ language committee issues seem to be pointing out that everyone better be abandoning that language as soon as possible if they wish to have any codebase that can be maintained for any length of time.

Rust also gives us the ability to define our in-kernel apis in ways that make them almost impossible to get wrong when using them. We have way too many difficult/tricky apis that require way too much maintainer review just to "ensure that you got this right" that is a combination of both how our apis have evolved over the years (how many different ways can you use a 'struct cdev' in a safe way?) and how C doesn't allow us to express apis in a way that makes them easier/safer to use. Forcing us maintainers of these apis to rethink them is a GOOD thing, as it is causing us to clean them up for EVERYONE, C users included already, making Linux better overall.

And yes, the Rust bindings look like magic to me in places, someone with very little Rust experience, but I'm willing to learn and work with the developers who have stepped up to help out here. To not want to learn and change based on new evidence (see my point about reading every kernel bug we have.)

Rust isn't a "silver bullet" that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going forward, why wouldn't we want that?

Linux is a tool that everyone else uses to solve their problems, and here we have developers that are saying "hey, our problem is that we want to write code for our hardware that just can't have all of these types of bugs automatically".

Why would we ignore that?

Yes, I understand our overworked maintainer problem (being one of these people myself), but here we have people actually doing the work!

Yes, mixed language codebases are rough, and hard to maintain, but we are kernel developers dammit, we've been maintaining and strengthening Linux for longer than anyone ever thought was going to be possible. We've turned our development model into a well-oiled engineering marvel creating something that no one else has ever been able to accomplish. Adding another language really shouldn't be a problem, we've handled much worse things in the past and we shouldn't give up now on wanting to ensure that our project succeeds for the next 20+ years. We've got to keep pushing forward when confronted with new good ideas, and embrace the people offering to join us in actually doing the work to help make sure that we all succeed together.

thanks,

greg k-h"

De som protesterar vet av erfarenhet att det inte är så världen fungerar. När beroendet på Rust växer så kan man i praktiken inte ändra något som gör sönder Rust-koden därför att det inte går att hålla deadline för nästa release då. Men det är inget du och jag behöver reda ut här och nu, utan det är bara att vänta ett par år och se vart det landar.