Re: Rust kernel policy

[Linus Torvalds]

On Wed, 19 Feb 2025 at 22:42, Christoph Hellwig <hch@xxxxxxxxxxxxx> 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