linux-kernel - 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: <293df3d54bad446e8fd527f204c6dc301354e340.camel@mailbox.org>
Date: Thu, 30 Jan 2025 14:19:16 +0100
From: Philipp Stanner <phasta@...lbox.org>
To: Christoph Hellwig <hch@....de>, Danilo Krummrich <dakr@...nel.org>
Cc: 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>, Greg KH <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction.

On Tue, 2025-01-28 at 10:23 +0100, Christoph Hellwig wrote:
> On Thu, Jan 16, 2025 at 02:17:24PM +0100, Danilo Krummrich wrote:
> > Since there hasn't been a reply so far, I assume that we're good
> > with
> > maintaining the DMA Rust abstractions separately.
> 
> No, I'm not.  This was an explicit:
> 
> Nacked-by: Christoph Hellwig <hch@....de>
> 
> And I also do not want another maintainer.  If you want to make Linux
> impossible to maintain due to a cross-language codebase do that in
> your driver so that you have to do it instead of spreading this
> cancer
> to core subsystems.  (where this cancer explicitly is a cross-
> language
> codebase and not rust itself, just to escape the flameware brigade).

Hallo,

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?
(because that's what the statements made by the latter seem to mean to
me)

As I see it, at least as long as Rust code is just drivers and
abstractions which sit on top of the core infrastructure, which is C,
breakages or a hypothetical unmaintainability would only affect the
Rust side, whereas the traditional kernel could go on working and being
maintained as it always did.

I'm thinking about something like a linux/LANGUAGES file, which
specifies what languages you can use and what the rules are. Written
down transparently black on white. As a counterpart to linux/LICENSES,
basically.

Philipp