Message-ID: <CAMwc25p1kGHjy7z19Kg+vv7yVc0bF2taA08hBKhk72e4HiK5xA@mail.gmail.com>
Date: Sun, 9 Feb 2025 16:44:10 +1000
From: David Airlie <airlied@...hat.com>
To: Carlos Bilbao <bilbao@...edu>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Christoph Hellwig <hch@....de>, 
	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>, 
	"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 Sun, Feb 9, 2025 at 9:55 AM Carlos Bilbao <bilbao@...edu> wrote:
>
> 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.
>

That is the process we are committed to, everyone has a voice and gets
to be heard, and we move forward in the appropriate manner with each
maintainer. Bypassing maintainers is the last resort, not engaging at
all with maintainers isn't a productive way forward either. Your below
attempt is trying to create a technical solution to a social problem.

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

This just adds overheads for everyone to little advantage for the
cases where maintainers are fine with all the other approaches.

Also the bindings code in rust is usually pretty trivial to change,
it's not like you can really abstract things that far, changing APIs
is hard no matter what, understanding the nuances in every C driver
can takes months of work adding rust bindings to your changes is
rarely going to be the limiting factor. We have learned over the years
to not make API changes that are subtle or hidden, and can leave out
of tree or in development users broken in subtle ways and as long as
we keep making API changes like that, updating the rust code is the
least of anyone's worries. This isn't like having to learn Mandarin vs
English, it's code written with a different syntax, it's not even
perl.

Dave.

Powered by blists - more mailing lists