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 for Android: free password hash cracker in your pocket

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

Message-ID: <1894f095-e93a-4def-a223-d5c089ecc2df@vt.edu>
Date: Sat, 8 Feb 2025 17:55:16 -0600
From: Carlos Bilbao <bilbao@...edu>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
 Christoph Hellwig <hch@....de>
Cc: 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>,
 Danilo Krummrich <dakr@...nel.org>, 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.

Hello,

On 1/8/25 09:16, Miguel Ojeda wrote:
> On Wed, Jan 8, 2025 at 3:00 PM Christoph Hellwig <hch@....de> wrote:
>>
>> No rust code in kernel/dma, please.
> 
> What do you suggest?

This is it. What do people suggest? This thread has received a lot of
attention -- maybe it's an opportunity for the community to brainstorm.
Here's an idea:

Some maintainers clearly hate wrappers/bindings to Rust, while others don't
mind as long as the R4L folks commit to the maintenance duties. Depending on
the subsystem, it will be a completely different conversation. It seems to
me that right now, every time the R4L folks interact with a new subsystem,
they need to understand the maintainer's stance. That looks like an
exhausting process.

Would it make sense to have a C middleman that Rust calls instead of
binding directly to the C funcs? This dispatcher would provide a simpler,
stable API with fixed function signatures, even if the C functions change.
If a C func is removed/changed, only the C dispatcher would need to be
adapted, but until that happens, a new error could be returned to the Rust
side (not ideal, but Rust doesn't just break). 

This would obviously impose some limitations on the Rust side, but it might
be less conflictive than direct bindings. Also, in Abdiel's case here (for
example), he'd explicitly take on the maintenance of the Rust abstraction
and its DMA dispatchers, leaving no ambiguity about ownership.

> 
> Thanks!
> 
> Cheers,
> Miguel
> 
> 

Thanks,
Carlos