Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Jan 30, 2025 at 11:46:46AM -0400, Jason Gunthorpe wrote:
> On Thu, Jan 30, 2025 at 02:19:16PM +0100, Philipp Stanner wrote:
> > would some sort of official statement by the "entire community"
> > 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?
> 
> You'd have to reconcile that with the recent event where Linus defered
> the MM pull request and some C patches were dropped because of rust
> kbuild bugs:
> 
> https://lore.kernel.org/linux-mm/CAHk-=whddBhfi5DUi370W3pYs+z3r2E7KYuHjwR=a1eRig5Gxg@mail.gmail.com/
> 
> It seems to me the message is now crystal clear, and the opposite of
> what you claim.
> 
> All PRs to Linus must not break the rust build and the responsibilty
> for that falls to all the maintainers. If the Rust team is not quick
> enough to resolve any issues during the development window then
> patches must be dropped before sending PRs, or Linus will refuse the
> PR.
> 
> Effectively this seems to imply that patches changing some of the C
> API cannot be merged by maintainers unless accompanied by matching
> Rust hunks.
> 
> If there are different instructions to maintainers I would be
> interested to know.

That's not the case, the one you point at above was a tooling issue that
people missed due to the holidays.  Fixing it up was simple enough and
people did so and moved on.

Once a core api changes in a tree and it hits linux-next and that blows
up a rust build, obviously people should notice it then and the rust
maintainers/developers have said they will fix it up.

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.

thanks,

greg k-h