linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: "Yury Norov" <yury.norov@gmail.com>,
	"Viresh Kumar" <viresh.kumar@linaro.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	"Danilo Krummrich" <dakr@redhat.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	linux-pm@vger.kernel.org,
	"Vincent Guittot" <vincent.guittot@linaro.org>,
	"Stephen Boyd" <sboyd@kernel.org>, "Nishanth Menon" <nm@ti.com>,
	rust-for-linux@vger.kernel.org,
	"Manos Pitsidianakis" <manos.pitsidianakis@linaro.org>,
	"Erik Schilling" <erik.schilling@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Joakim Bech" <joakim.bech@linaro.org>,
	"Rob Herring" <robh@kernel.org>, "Christoph Hellwig" <hch@lst.de>,
	linux-kernel@vger.kernel.org, "Uros Bizjak" <ubizjak@gmail.com>
Subject: Re: [PATCH V8 04/14] rust: Add cpumask helpers
Date: Fri, 14 Feb 2025 17:06:37 -0400	[thread overview]
Message-ID: <20250214210637.GK3886819@nvidia.com> (raw)
In-Reply-To: <CANiq72=tDhUEjdBmVTPv4cFeD8iiKwJAQD3Cb1=Y4KnE-vh2OQ@mail.gmail.com>

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@nvidia.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

  reply	other threads:[~2025-02-14 21:06 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-06  9:28 [PATCH V8 00/14] Rust bindings for cpufreq and OPP core + sample driver Viresh Kumar
2025-02-06  9:28 ` [PATCH V8 01/14] rust: macros: enable use of hyphens in module names Viresh Kumar
2025-02-06  9:28 ` [PATCH V8 02/14] cpufreq: Use enum for cpufreq flags that use BIT() Viresh Kumar
2025-02-06  9:28 ` [PATCH V8 03/14] rust: cpu: Add from_cpu() Viresh Kumar
2025-02-06  9:28 ` [PATCH V8 04/14] rust: Add cpumask helpers Viresh Kumar
2025-02-11  0:02   ` Yury Norov
2025-02-11  4:29     ` Viresh Kumar
2025-02-11 16:24       ` Yury Norov
2025-02-11 16:49         ` Jason Gunthorpe
2025-02-11 17:27         ` Danilo Krummrich
2025-02-11 21:37         ` Miguel Ojeda
2025-02-14  2:20           ` Yury Norov
2025-02-14  3:36             ` Viresh Kumar
2025-02-14 17:56             ` Miguel Ojeda
2025-02-14 19:11               ` Jason Gunthorpe
2025-02-14 20:24                 ` Miguel Ojeda
2025-02-14 21:06                   ` Jason Gunthorpe [this message]
2025-02-14 22:36                     ` Miguel Ojeda
2025-02-15  9:55                       ` Andreas Hindborg
2025-02-17  9:45                     ` Philipp Stanner
2025-02-14 20:58                 ` Miguel Ojeda
2025-02-12  7:34         ` Viresh Kumar
2025-02-15 10:16           ` Andreas Hindborg
2025-02-06  9:28 ` [PATCH V8 05/14] rust: Add bindings for cpumask Viresh Kumar
2025-02-06  9:28 ` [PATCH V8 06/14] rust: Add bare minimal bindings for clk framework Viresh Kumar
2025-02-06 11:49   ` Danilo Krummrich
2025-02-06 11:52     ` Danilo Krummrich
2025-02-06 20:05       ` Stephen Boyd
2025-02-06 23:11         ` Danilo Krummrich
2025-02-07  9:24           ` Viresh Kumar
2025-02-07 10:43             ` Viresh Kumar
2025-02-07 17:19             ` Danilo Krummrich
2025-02-10  8:06               ` Viresh Kumar
2025-02-10 22:07           ` Stephen Boyd
2025-02-17 12:19   ` Daniel Almeida
2025-02-21  6:35     ` Viresh Kumar
2025-02-06  9:28 ` [PATCH V8 07/14] rust: Add initial bindings for OPP framework Viresh Kumar
2025-02-06  9:28 ` [PATCH V8 08/14] rust: Extend OPP bindings for the OPP table Viresh Kumar
2025-02-06  9:28 ` [PATCH V8 09/14] rust: Extend OPP bindings for the configuration options Viresh Kumar
2025-02-06  9:28 ` [PATCH V8 10/14] rust: Add initial bindings for cpufreq framework Viresh Kumar
2025-02-06  9:28 ` [PATCH V8 11/14] rust: Extend cpufreq bindings for policy and driver ops Viresh Kumar
2025-02-06  9:28 ` [PATCH V8 12/14] rust: Extend cpufreq bindings for driver registration Viresh Kumar
2025-02-06 12:04   ` Danilo Krummrich
2025-02-06 12:06     ` Alice Ryhl
2025-02-07  9:15     ` Viresh Kumar
2025-02-06  9:28 ` [PATCH V8 13/14] rust: Extend OPP bindings with CPU frequency table Viresh Kumar
2025-02-06  9:28 ` [PATCH V8 14/14] cpufreq: Add Rust based cpufreq-dt driver Viresh Kumar
2025-02-06 11:45 ` [PATCH V8 00/14] Rust bindings for cpufreq and OPP core + sample driver Danilo Krummrich
2025-02-07  7:15   ` Viresh Kumar
2025-02-07 11:07     ` Miguel Ojeda
2025-02-10  8:06       ` Viresh Kumar
2025-02-17  8:39         ` Miguel Ojeda
2025-02-17 10:18           ` Viresh Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250214210637.GK3886819@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=a.hindborg@kernel.org \
    --cc=alex.bennee@linaro.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@redhat.com \
    --cc=erik.schilling@linaro.org \
    --cc=gary@garyguo.net \
    --cc=hch@lst.de \
    --cc=joakim.bech@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=manos.pitsidianakis@linaro.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=nm@ti.com \
    --cc=ojeda@kernel.org \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=sboyd@kernel.org \
    --cc=tmgross@umich.edu \
    --cc=ubizjak@gmail.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=yury.norov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).