Re: [PATCH 1/3] dma-buf: dma-fence: Add flags parameter to dma_fence_init()

[Philipp Stanner <phasta@mailbox.org>]

-Cc rust-for-linux, since it was typo'ed and now misses the thread anyways..

On Thu, 2026-11-05 at 13:35 +0100, Christian König wrote:
> On 11/5/26 13:06, Tvrtko Ursulin wrote:
> > 
> > [I aggresively rewrote the To: list because my SMTP won't let me
> > send this as it was.]
> > 
> > On 05/11/2026 11:35, Philipp Stanner wrote:
> > > Currently, there are two init functions for dma_fence,
> > > dma_fence_init()
> > > and dma_fence_init64().
> > > 
> > > Since more future user options for dma_fence initialization would
> > > require distinct init functions, too, it is better to do this in
> > > a
> > > unified way.
> > 
> > Why not add something like dma_fence_init_flags() and leave the 99%
> > of the callers out of the (huge) diff? Ie. just port
> > dma_fence_init64() to dma_fence_init_flags().
> 
> Well one advantage of the Linux kernel is to avoid such wrappers. I
> think having more than one function for the same thing basically just
> adds more confusion.

Do you think all future users would want SEQNO64 by default, btw?

> 
> That's also why I would really like to just have one
> dma_fence_signal() and not like five (or was it four?) variants.

It should be dma_fence_signal(fence, error), anihilating
dma_fence_set_error(), which is just another massive incentive to add
race conditions.


P.