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: <Z6nTxks3u-ErSalQ@cassiopeiae>
Date: Mon, 10 Feb 2025 11:24:06 +0100
From: Danilo Krummrich <dakr@...nel.org>
To: Icenowy Zheng <uwu@...nowy.me>
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.)

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.

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