linux-kernel - Re: [RFC 1/5] locking: MAINTAINERS: Start watching Rust locking primitives

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: <CANiq72=KA205nyWGxaFpuq-FRV9SXsimCsiZAhrsyX9dA37+rA@mail.gmail.com>
Date: Thu, 5 Dec 2024 12:39:44 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Lyude Paul <lyude@...hat.com>, Ingo Molnar <mingo@...hat.com>, 
	Peter Zijlstra <peterz@...radead.org>, Miguel Ojeda <ojeda@...nel.org>, Will Deacon <will@...nel.org>, 
	Waiman Long <longman@...hat.com>, Alex Gaynor <alex.gaynor@...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>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Filipe Xavier <felipe_life@...e.com>
Subject: Re: [RFC 1/5] locking: MAINTAINERS: Start watching Rust locking primitives

On Wed, Dec 4, 2024 at 10:04 PM Boqun Feng <boqun.feng@...il.com> wrote:
>
> Thanks! Yes, it'll be great to have more people watching this. And thank
> you for the review and contribution so far, nice job!

Indeed -- thanks Lyude!

> I'm currently waiting for both lock maintainers and Rust maintainers
> opinions on the particular changes on the MAINTAINERS file (for example,
> maybe they want something similar to "RUST [ALLOC]" entry, i.e. a
> standalone entry). My plan is to send the PR after everyone is on the
> same page. And you're welcome to send a patch adding yourself in the
> entry afterwards.

Up to you! :)

I guess it depends on whether the rest of the locking maintainers want
to see every patch related to that (which would be great) or not,
whether you want to have finer-grained control on who gets pinged,
potentially different "M:" level and so on. For instance, it would
allow you to have an explicit "L:" for the Rust for Linux list.

By the way, as a third alternative, you could also consider a
sub-entry in locking, too, i.e. "LOCKING PRIMITIVES [RUST]" as a
middle ground, which would allow you to keep routing patches through
locking but have the benefits of a sub-entry if you need them.

Whatever you decide:

Acked-by: Miguel Ojeda <ojeda@...nel.org>

Thanks!

Cheers,
Miguel