Re: [PATCH V8 04/14] rust: Add cpumask helpers

[Yury Norov <yury.norov@gmail.com>]

Hi Miguel,

On Tue, Feb 11, 2025 at 10:37:26PM +0100, Miguel Ojeda wrote:
> On Tue, Feb 11, 2025 at 5:24 PM Yury Norov <yury.norov@gmail.com> wrote:
> >
> > No, not Okay.
> >
> > To begin with, this is the 8th version of the same patch, but you
> > only now bothered to CC someone who is listed in MAINTAINERS. This is
> > not how the community works.
> 
> Yeah, that is not good.
> 
> For what it is worth, we try to make this very clear:
> 
>     https://rust-for-linux.com/contributing#submitting-new-abstractions-and-modules
> 
> i.e. that maintainers need to be Cc'd and contacted as soon as
> possible (possibly even before writing the code).
> 
> > You also made it a patch bomb that touches multiple critical and very
> > sensitive subsystems. You link them to an experimental and unstable
> > project, and do it in a way that makes it really easy to slip through
> > maintainers' attention.
> 
> Not sure what you mean by "unstable project", but I agree that the

I mean that Andrew's branch got broken because of it.

> patch series, unless Viresh is the maintainer of the C side of
> everything added, it should be discussed and maintenance discussed
> accordingly before merging anything.
> 
> This is what we have done for everything else, and that has not changed.
> 
> I try to spot cases where this is not done, which is why I Cc'd you in
> v7 and told Viresh to please do so, and he did -- I don't think he was
> trying to bypass on purpose:
> 
>     https://lore.kernel.org/rust-for-linux/CANiq72=o+uc3ZnNrdkuoSGSL8apNE4z4QwpvsiLfGzXFywSLrQ@mail.gmail.com/

Yes, I see. Viresh didn't do that on purpose. Let's move forward. I'm
more concerned about lack of testing on rust side that ended up with
the patches withdrawal.
 
> > That would make things even worse. Before you wanted me to maintain
> > rust linkage. Now you want me to get approval from someone else who
> > maintains rust linkage. In case I need to change something, I want to
> > be able to just change.
> 
> Like Danilo mentions, there are several ways to go forward here. For
> some ideas/context, please see:
> 
>     https://rust-for-linux.com/rust-kernel-policy#how-is-rust-introduced-in-a-subsystem
> 
> (Thanks Jason for linking the page)
> 
> And, yeah, whoever ends up maintaining this, then they should of
> course be testing it properly with Rust enabled with a proper config
> for that and so on, just like one would do for anything else. By the
> way, it is possible to request Intel's 0day to build with Rust
> enabled.

Yes, this should be done. 0-day is already testing everything in my 
https://github.com/norov/linux repo. If you know right people, please
ask them to test bitmap-for-next branch with rust enabled. If there's
enough resources, please cover all the repo.

> (Side-note: to clarify, there are different parties involved here --
> "Rust team" is fairly ambiguous.)
>
> Cheers,
> Miguel

I'm the right person to look after rust bindings for bitops, inevitably.
I will take over patch 4/14 and submit it separately together with a
new maintenance entry.

I will not maintain any rust code. For 5/14, after I'll send my series,
Viresh, can you submit 5/14 separately and create a separate entry in
MAINTAINERS. Please make me a reviewer there.

I'll think about details over the weekend and will submit everything
early next week.

Rasmus, if you would like to help me reviewing this thing, please let
me know.

Thanks,
Yury