linux-kernel - Re: On community influencing (was Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d7d1fb8af8857e7ebfdea48213849ea9ba446477.camel@icenowy.me>
Date: Thu, 13 Feb 2025 11:49:20 +0800
From: Icenowy Zheng <uwu@...nowy.me>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Hector Martin <marcan@...can.st>, Steven Rostedt <rostedt@...dmis.org>, 
 "Dr. Greg" <greg@...ellic.com>, Linus Torvalds
 <torvalds@...ux-foundation.org>, Dave Airlie <airlied@...il.com>, Jason
 Gunthorpe <jgg@...dia.com>, Greg KH <gregkh@...uxfoundation.org>,
 phasta@...nel.org, Christoph Hellwig <hch@....de>,  Miguel Ojeda
 <miguel.ojeda.sandonis@...il.com>, Abdiel Janulgue
 <abdiel.janulgue@...il.com>,  daniel.almeida@...labora.com,
 aliceryhl@...gle.com, robin.murphy@....com, 
 rust-for-linux@...r.kernel.org, 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>,
 Trevor Gross <tmgross@...ch.edu>, Valentin Obst <kernel@...entinobst.de>,
 open list <linux-kernel@...r.kernel.org>, Marek Szyprowski
 <m.szyprowski@...sung.com>,  airlied@...hat.com, "open list:DMA MAPPING
 HELPERS" <iommu@...ts.linux.dev>,  DRI Development
 <dri-devel@...ts.freedesktop.org>
Subject: Re: On community influencing (was Re: [PATCH v8 2/2] rust: add dma
 coherent allocator abstraction.)

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