Message-ID: <CANiq72mM3tVmT6MQZqpzGEW4hJABVHRiODL0SnP2u+0ES4=pjw@mail.gmail.com>
Date: Fri, 21 Feb 2025 00:44:31 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: 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 Thu, Feb 20, 2025 at 7:42 AM Christoph Hellwig <hch@...radead.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.
>
> That is a very dishonest way of communication.
>
> And while you might not have known that when
> writing the document, you absolutely did when posting it to the list.

I did know -- Linus told both of us in the private thread. I am not
sure what that has to do with anything.

As I told you in the previous reply, please read the next paragraph of
the document:

    Now, in the Kernel Maintainers Summit 2022, we asked for flexibility
    when the time comes that a major user of Rust in the kernel requires
    key APIs for which the maintainer may not be able to maintain Rust
    abstractions for it. This is the needed counterpart to the ability
    of maintainers to decide whether they want to allow Rust or not.

The point is that maintainers decide how to handle Rust (and some have
indeed rejected Rust), but that flexibility is needed if a maintainer
that owns a core API does not want Rust, because otherwise it blocks
everything, as is your case.

In summary: you were in that meeting, you own a core API, you do not
want Rust, you are blocking everything. So flexibility is needed. Thus
we asked you what can be done, how we can help, etc. You did not
accept other maintainers, did not want to have the code anywhere in
the tree, nor wanted to work on a compromise at all. You, in fact,
said "I will do everything I can do to stop this.". So that is not
providing flexibility, quite the opposite of it. So Linus eventually
had to make a decision to provide that flexibility.

I am not sure how that contradicts the document -- the document is
precisely talking about this situation.

By the way, I do not take lightly that you accuse me of dishonesty.

> Which given the binding creep means every single non-leaf subsystem
> eventually.

If Rust keeps growing in the kernel, then obviously more and more
non-leaf maintainers get affected.

But that just means more people is getting involved and more
subsystems are accepting Rust for their use cases. So that would just
mean it was, indeed, a good idea in the end.

> I'm not sure how that matters.  Of course your Rust testimonials are
> going to like it, otherwise you would not have quoted it.  They

Not at all. As I say in the talk, I included every single quote I got,
even up to the night before the keynote.

It is nevertheless very biased, because I asked people we interacted
with, which were mostly positive or neutral. I acknowledged this bias
in the talk too.

However, just so that others are aware, I did email others that are
negative about it too, such as you. And you did not reply.

> Well, obviously you do.  But as in many other things I would usually
> not count corporate pressure as a good thing.

Corporate pressure is not good. Corporate support is.

And we need that support to accomplish something like this.

Cheers,
Miguel

Powered by blists - more mailing lists