Re: [RFC PATCH] rust: sync: Add dma_fence abstractions

[Boqun Feng]

On Sat, Sep 27, 2025 at 11:01:38AM +0200, Philipp Stanner wrote:
[..]
> > > ---
> > >  rust/bindings/bindings_helper.h |   1 +
> > >  rust/helpers/dma_fence.c        |  23 ++
> > >  rust/helpers/helpers.c          |   1 +
> > >  rust/helpers/spinlock.c         |   5 +
> > >  rust/kernel/sync.rs             |   2 +
> > >  rust/kernel/sync/dma_fence.rs   | 388 ++++++++++++++++++++++++++++++++
> > 
> > I missed this part, and I don't think kernel::sync is where dma_fence
> > should be, as kernel::sync is mostly for the basic synchronization
> > between threads/irqs. dma_fence is probably better to be grouped with
> > dma-buf and other dma related primitives. Maybe in kernel::dma? Like:
> > 
> > rust/kernel/dma.rs
> > rust/kernel/dma/dma_buf.rs
> > rust/kernel/dma/dma_fence.rs
> > 
> > Thoughts? Miguel, Greg, Danilo and Lyude, any idea or suggestion?
> 
> @Christian König's opinion would be valuable, too.
> 
> I'm not super convinced of that because dma_fence has not really much
> to do with DMA. They're not very different from completions and are a
> mechanism to synchronize consumers and producers.
> 
> Actually, before f54d1867005c3 they were just called "fence" and then
> renamed to "dma_fence" because someone wanted that name.
> 

Well, dma-fence.c lives in drivers/dma-buf/, and IIUC it will only be
built in CONFIG_DMA_SHARED_BUFFER is selected. They are enough evidences
to show that dma_fence is not considered as a general fence. Of course,
the implementation of dma_fence may not be tied to any DMA
functionality, but before we make it a general fence in Rust, we need to
at least change it in C as well.

Regards,
Boqun

> 
> Anyways, I don't have strong objections and mostly care about having
> them available somewhere.
> 
> P.
> 
> > 
> > Regards,
> > Boqun
> > 
> > >  6 files changed, 420 insertions(+)
> > >  create mode 100644 rust/helpers/dma_fence.c
> > >  create mode 100644 rust/kernel/sync/dma_fence.rs
> > > 
> > [...]
>