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: <CANiq72mFKNWfGmc5J_9apQaJMgRm6M7tvVFG8xK+ZjJY+6d6Vg@mail.gmail.com>
Date: Fri, 14 Feb 2025 23:36:57 +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>, 
	Greg KH <gregkh@...uxfoundation.org>, Philipp Stanner <phasta@...lbox.org>, 
	Jens Axboe <axboe@...nel.dk>
Subject: Re: [PATCH V8 04/14] rust: Add cpumask helpers

On Fri, Feb 14, 2025 at 10:06 PM Jason Gunthorpe <jgg@...dia.com> wrote:
>
> 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.

We cannot be expected to chase down every maintainer in all online fora.

Not just because it is not viable, but because hopefully this is not
about who shouts the loudest (== more often).

Moreover, we do not have the authority to set policy ourselves, and we
are not in the business of forcing things into other subsystems.

Now, if you are a maintainer, and you want to deal with Rust in the
kernel, then please do any of the following: send us an email, join
our talks, read the LWN articles about our talks (but do not assume
LWN comments are "consensus" somehow), join our MC in LPC, join
Kangrejos, and so on and so forth.

We have been open to talk to every single maintainer that wanted to
use Rust or that we needed to interface with, and other maintainers
can tell you that we have successfully worked with them.

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

Sure, and that is why we talked to the actual, relevant, maintainers
and subsystems that are taking patches that are related to Rust.

We may not have talked to you directly or explain things to you, but
that does not mean we didn't talk to others.

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

Very happy to do so if others are happy with it.

I published it in the website because it is not a document the overall
kernel community signed on so far. Again, we do not have that
authority as far as I understand.

The idea was to clarify the main points, and gather consensus. The
FOSDEM 2025 keynote quotes were also intended in a similar way:

    https://fosdem.org/2025/events/attachments/fosdem-2025-6507-rust-for-linux/slides/236835/2025-02-0_iwSaMYM.pdf

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

In my emails in this thread, "we" means the Rust subsystem entry.

> 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"?

No, he is not part of the Rust subsystem entry, as you can easily
verify in the `MAINTAINERS` file.

And I can not speak for him either.

He, of course, has helped us a lot, like other kernel maintainers have.

By the way, the document, at the top, mentions:

    Like most things in the kernel, these points are not hard rules
and can change over time depending on the situation and what key
maintainers and the kernel community discuss.

> I think it was very clear, sorry, I don't read it your many ways at
> all.

Well, then please ask Greg, not us, and remember to Cc him, by the way.

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

Please ask Jens and the block layer -- Cc'ing Jens (Andreas and Boqun
are already Cc'd):

    https://lore.kernel.org/all/593a98c9-baaa-496b-a9a7-c886463722e1@kernel.dk/

Having said that, I am not sure what you mean by -rc1. It is in the
context of a friendly collaboration -- I assume the intention is that
Andreas et al. are given enough lead time on new features to fix them
before the merge window. For fixes, it may be harder, of course. Other
ideas: they may be able to config out certain parts too; or in the
worst case, in an emergency, Linus may decide to break Rust. They may
be able to tell you the details of their plan.

> It is, but also I think you need to take this challenge to succeed.

In fact, we are, and I explained above all the ways we are engaging
with maintainers and so on.

Please note that the fact that we may not tackle the challenge in the
way you would like does not mean we are not doing it.

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

We have never (intentionally) claimed that. We may have spoken
unclearly, we may have been misinterpreted by others, and we have
always been open for clarification.

Please see my previous email.

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

Again, to be clear: the approach we have followed has been quite clear
if you actually spoke to us, instead of taking for granted what
unrelated people may have posted.

> There is another we :)

I am not sure what you are trying to achieve here.

Cheers,
Miguel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ