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

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Feb 14, 2025 at 06:56:43PM +0100, Miguel Ojeda wrote:

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

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

Sure, but it was said, by many people, many times, that "Rust is
allowed to break".

This is not just my incorrect impression. For instance read Philipp's
note to Christoph:

https://lore.kernel.org/all/293df3d54bad446e8fd527f204c6dc301354e340.camel@mailbox.org/

 > reassure you that the burden of keeping Rust abstractions working with
 > any changes on the C side rests entirely on the Rust side's shoulders?
 > (because that's what the statements made by the latter seem to mean to
 > me)

And Greg's version:

https://lore.kernel.org/all/2025013030-gummy-cosmic-7927@gregkh/

 > So the claim remains the same here.  It's just like staging, api changes
 > to subsystems are allowed to break staging, and rust code, and
 > maintainers do NOT have to fix them up there, that's up to the staging
 > and rust maintainers/developers to do so.

I've heard the same statements at conferences and in other coverages
like LWN. Frankly, I never much believed in this story as workable,
but it was advanced by many people to smooth the adoption of Rust
bindings.

>    https://rust-for-linux.com/rust-kernel-policy#didnt-you-promise-rust-wouldnt-be-extra-work-for-maintainers

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.

However, I am glad we are seeing a more realistic understanding of
what Rust requires of the community over the long term.

Jason