lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250214210637.GK3886819@nvidia.com>
Date: Fri, 14 Feb 2025 17:06:37 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: 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, 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.

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 :)

Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ