Message-ID: <CANiq72=tDhUEjdBmVTPv4cFeD8iiKwJAQD3Cb1=Y4KnE-vh2OQ@mail.gmail.com>
Date: Fri, 14 Feb 2025 21:24:31 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Yury Norov <yury.norov@...il.com>, Viresh Kumar <viresh.kumar@...aro.org>, 
	"Rafael J. Wysocki" <rafael@...nel.org>, Danilo Krummrich <dakr@...hat.com>, Miguel Ojeda <ojeda@...nel.org>, 
	Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>, 
	Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, 
	Rasmus Villemoes <linux@...musvillemoes.dk>, linux-pm@...r.kernel.org, 
	Vincent Guittot <vincent.guittot@...aro.org>, Stephen Boyd <sboyd@...nel.org>, 
	Nishanth Menon <nm@...com>, rust-for-linux@...r.kernel.org, 
	Manos Pitsidianakis <manos.pitsidianakis@...aro.org>, Erik Schilling <erik.schilling@...aro.org>, 
	Alex Bennée <alex.bennee@...aro.org>, 
	Joakim Bech <joakim.bech@...aro.org>, Rob Herring <robh@...nel.org>, Christoph Hellwig <hch@....de>, 
	linux-kernel@...r.kernel.org, Uros Bizjak <ubizjak@...il.com>
Subject: Re: [PATCH V8 04/14] rust: Add cpumask helpers

On Fri, Feb 14, 2025 at 8:11 PM Jason Gunthorpe <jgg@...dia.com> wrote:
>
> Sure, but it was said, by many people, many times, that "Rust is
> allowed to break".

A lot of people have said many things (especially in online fora), and
many of those things are contradictory, but that does not really mean
anything.

> This is not just my incorrect impression. For instance read Philipp's
> note to Christoph:
>
> https://lore.kernel.org/all/293df3d54bad446e8fd527f204c6dc301354e340.camel@mailbox.org/

Philipp probably sent that message with his best intentions, but he is
not part of the Rust subsystem nor speaks on our behalf.

He may have been speaking for other groups, or maybe just his own
opinion -- I do not know.

Moreover, sometimes suggestions like his may be referring to
particular subsystems (like the one that was discussed in that
thread), e.g. like block decided to take an approach where Rust is
allowed to break, rather than speaking globally.

Finally, ambiguous terms are used in many cases to refer to different
parties: "Rust community", "Rust people", "Rust team", "Rust
maintainers"... I have started to ask people to avoid doing that (at
least in the LKML), please, and be concrete if possible.

> And Greg's version:
>
> https://lore.kernel.org/all/2025013030-gummy-cosmic-7927@gregkh/

I cannot speak for Greg, sorry.

I can read his message in the following ways:

  - I can read it as a general ability of subsystems to potentially
agree to treat Rust code as something like staging, like block's plan.

  - I can read it within the context of those patches, where, as far
as I know, Danilo et al. stepped up to maintain it, like Andreas did
for block.

  - I can read it as the fact that the Rust subsystem will help,
best-effort, to bootstrap Rust and help with integration where
possible.

We need maintainers' help and expertise from other subsystems to
succeed. And we do not want to force other subsystems into dealing
with Rust. That is why the deal was that we would contact and wait for
other subsystems to handle Rust and so on. It is also why I asked, in
the very meeting where it was decided to merge Rust, that in exchange,
we would eventually need some flexibility by maintainers that may not
want Rust in their subsystem but that nevertheless may be the owners
of core APIs that other users of Rust in the kernel need. I did so
because I knew the day would come we would be in the situation we are
in that email thread.

> I've heard the same statements at conferences and in other coverages
> like LWN. Frankly, I never much believed in this story as workable,
> but it was advanced by many people to smooth the adoption of Rust
> bindings.

Again, people may make statements, but they may be local to their
subsystem, or just their opinion, or it may be a misunderstanding, and
so on and so forth.

It is very hard to keep hundreds of maintainers on the same page.

> I do not agree with "Didn't you promise Rust wouldn't be extra work
> for maintainers?" in your document. Clearly there is a widespread
> belief this kind of promise was made, even if it was never made by
> you. "Rust is allowed to break" is understood to be the same as saying
> it won't cause extra work.

Sorry, but I have to strongly push back against this paragraph.

Are you really saying that, because people out there may think
something, we cannot claim anymore that we did not promise something?

Furthermore, I don't agree with your assessment in your last sentence
at all. Even if it was decided to allow Rust to break globally and at
all times, it does not mean Rust is not extra work. It is, because
collaboration would be still needed with different subsystems and so
on. The plan has always been to not have Rust be something hidden in a
corner. For instance, see from 2020:

    https://lore.kernel.org/all/CAHk-=wipXqemHbVnK1kQsFzGOOZ8FUXn3PKrZb5WC=KkgAjRRw@mail.gmail.com/

> However, I am glad we are seeing a more realistic understanding of
> what Rust requires of the community over the long term.

That is good, but to be clear, from my point of view, the approach
mentioned in the document I wrote is what we have always said.

Cheers,
Miguel

Powered by blists - more mailing lists