Message-ID: <55a58a606cbd2afd86f83a89b9843e8c7d88c9f6.camel@mailbox.org>
Date: Mon, 17 Feb 2025 10:45:17 +0100
From: Philipp Stanner <phasta@...lbox.org>
To: Jason Gunthorpe <jgg@...dia.com>, Miguel Ojeda
	 <miguel.ojeda.sandonis@...il.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, 2025-02-14 at 17:06 -0400, Jason Gunthorpe wrote:
> On Fri, Feb 14, 2025 at 09:24:31PM +0100, Miguel Ojeda wrote:
> > 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.
> 
> We don't have a community where there is a clear authority
> structure. If lots of people are repeating a thing, that thing
> usually
> becomes the consensus and common viewpoint regardless of who
> originated it. The repetition reflects community agreement and buy in
> of the idea.
> 
> At the end of the day, only the policy adopted by the people merging
> patches really matters.
> 
> The assumption being if respected people speak with authority on a
> policy they have also got buy in from the people responsible to
> execute it.
> 
> I also think you should merge your policy document to the tree, not
> keep it on a web page. That seems to be a big part of getting
> community agreed policy adopted.
> 
> > 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.
> 
> Okay, that makes lots of seense. Please don't use "we" as well.. I
> have no idea who is included in your "we", or what to even call it.
> 
> > > And Greg's version:
> > > 
> > > https://lore.kernel.org/all/2025013030-gummy-cosmic-7927@gregkh/
> > 
> > I cannot speak for Greg, sorry.
> 
> Yet he does seems to be speaking with authority on this topic. His
> message was quoted on LWN and likely was read by a large number of
> maintainers.
> 
> Is he not part of your "we"?
> 
> > I can read his message in the following ways:
> 
> I think it was very clear, sorry, I don't read it your many ways at
> all.
> 
> >   - 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.
> 
> As a side note, I don't see how anyone can enact this plan without
> the
> support of Linus to do CONFIG_RUST=n builds and put out a non-working
> rc1. IMHO it is yet unclear if this is real thing or an unproven idea
> block has that will run into problems.
> 
> > It is very hard to keep hundreds of maintainers on the same page.
> 
> It is, but also I think you need to take this challenge to succeed.
>  
> > > 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?
> 
> Again "we" ?
> 
> I'm not concerned about "people out there". Greg said it. Others who
> I
> would think are part of your "we" have posted it on LKML.
> 
> It is not clear at all. If you said Miguel never claimed it, then I
> would not complain. You said it correctly above, be concrete. Ideally
> acknowledge there were different policy ideas in wide circulation,
> but
> they did not get adopted.
> 
> > 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. 
> 
> I appreciate this point is realistically true, but look at how
> Philipp
> presented this 'no break' concept to Christoph as a no-work option
> for
> him.

Hello,

so to clarify that: I'm (currently) not writing or maintaining any Rust
abstractions. So I'm not representing official projects, so take the
statement for what it's worth. I mainly wanted to probe how an
agreement with Christoph could have been worked out.

My main point still holds up, though:
The rules should be written down. In tree, in linux/

As you, Jason, also state, this would enforce a discussion leading to
more clarity.


> 
> My main point here is that I'm glad things are getting straightened
> out, some of the conflicting policy ideas shot down, and the demands
> on maintainers are being articulated more clearly.
> 
> > 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.
> 
> There is another we :)

The current, apparent, distinction between Rust and non-Rust kernel
engineers might indeed be a symbol for an underlying big question. 10
years down the road, will there still be "Rust people" who take care
of… the compiler? The abstractions and bindings? Are there "Clang
people and GCC people" currently, too?

That question goes deeper than one might think, because it's ultimately
about who maintains what and, as we already discussed, who can break
what. If, in the mid-future, subsystem maintainers uninvolved with Rust
couldn't merge changes that break Rust anymore, that *might* de facto
indeed lead to them having to learn that language. Or everyone would
need a Rust-proficient co-maintainer who can deal with those breakages;
or similar solutions.

So that's why I think clarifying it rather sooner than later is
necessary.


P.


> 
> Jason
> 

Powered by blists - more mailing lists