Message-ID: <CANiq72=Yy8e=pGA+bUHPZhn+D66TmU3kLSjAXCSQzgseSYnDxQ@mail.gmail.com>
Date: Fri, 14 Feb 2025 18:56:43 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Yury Norov <yury.norov@...il.com>
Cc: 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>, 
	Jason Gunthorpe <jgg@...dia.com>, 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 3:20 AM Yury Norov <yury.norov@...il.com> wrote:
>
> I mean that Andrew's branch got broken because of it.

(This response is extra verbose to be extra clear, given the recent
discussions these last days -- I don't mean you said or implied any of
this, sorry)

To be clear: it was not a patch we introduced that broke it. It was a
patch series from someone else that got a Linaro build report and
that, nevertheless, was sent to Linus.

The build report reached our mailing list, but we were not Cc'd
directly about it (i.e. as individuals), we were not pinged about it
(i.e. we never had any further questions about that after that single
day), and we didn't realize the series was kept in a queue targeting
Linus.

Moreover, the build failure happened with a configuration that is
best-effort and is documented as very experimental (GCC mixed builds),
and that we didn't know Linus was building (we knew he built with
Clang+Rust, which is what we are focused on testing), so we didn't
spot that either on our side.

By the way, we have not been Cc'd in the new version, either... Nor
the mailing list.

To be clear, I am not blaming anyone for the breakage, and I already
apologized that we didn't notice that report. But it is not our fault
either.

We also never promised we would fix every single Rust issue spotted
across the entire kernel. We try to do our best to help, though.

    https://rust-for-linux.com/rust-kernel-policy#who-is-responsible-if-a-c-change-breaks-a-build-with-rust-enabled
    https://rust-for-linux.com/rust-kernel-policy#didnt-you-promise-rust-wouldnt-be-extra-work-for-maintainers

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

Please see above.

I regularly test different combinations (branches, configs, compiler
versions, and so on) to catch mainly toolchain issues and so on, and
keep things as clean as I can. Others use regularly the Rust support
for their different use cases, thus more testing happens on different
environments. In other words, things generally work just fine.

However, our testing is not meant to catch every issue everywhere.
Like for anything else in the kernel, whoever maintains a branch with
a particular Rust feature needs to set up proper testing for that
particular feature and relevant configs.

Regarding the GCC mixed builds: worst case, if we see there is no
bandwidth for it (be it ourselves or other maintainers testing their
own branches), we could limit the testing required (e.g. limiting GCC
versions when Rust is enabled), or we could request Linus to skip Rust
with GCC in his builds, so that at least PRs are not blocked on that.

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

Definitely! I will do that and Cc you.

I hope that helps.

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

Thanks a lot Yury, that sounds very reasonable.

Cheers,
Miguel

Powered by blists - more mailing lists