On community influencing (was Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.)
Icenowy Zheng
uwu at icenowy.me
Thu Feb 13 03:49:20 UTC 2025
在 2025-02-10星期一的 11:24 +0100,Danilo Krummrich写道:
> On Mon, Feb 10, 2025 at 05:41:30PM +0800, Icenowy Zheng wrote:
> > Furtherly, the monorepo nature of Linux kernel means to refactor an
> > interface, it's usually the person changing the callee that need to
> > change all callers to satify the interface change; having Rust code
> > in
> > tree calling the interface effectively means adding the
> > responsibility
> > of fixing the Rust code when the interface changes, which could be
> > not
> > acceptable by the C-only maintainers. In regards of adding a
> > maintainer, having more maintainers means more communication.
>
> This is exactly the same as for every new driver / component,
> regardless of
> whether it is written in C or in Rust.
>
> It is absolutely common that driver maintainers help with integrating
> core API
> changes, if necessary.
>
> I don't see why the same process should not work for Rust
> abstractions.
Because integrating API changes could involve change to contexts of API
calls, which could be difficult for Rust situation, especially when
it's not required for core API maintainers to be able to write Rust.
>
> (Additionally, in this particular case even one of the reviewers of
> DMA MAPPING HELPERS offered to be a reviewer of the Rust abstractions
> too, in
> order to keep eye on the DMA API angle.)
Sorry, but I did a fact check on this, and I found that the only
"reviewer" of DMA MAPPING HELPERS is Robin Murphy, he has only one
reply in this thread, and the reply only says "Indeed, FWIW it seems
like the appropriate level of abstraction to me,
judging by the other wrappers living in rust/kernel/ already", he
didn't offer to be a reviewer, and he still says "Rust folks are happy
to take responsibility for un-breaking the
Rust build if and when it happens".
He is just saying he's going to accept the abstraction, which should be
not able to forcibly override Christoph's explicit NACK here.
More information about the dri-devel
mailing list