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

[Philipp Stanner]

On Thu, 2026-11-05 at 12:51 +0000, Tvrtko Ursulin wrote:
> On 05/11/2026 12:35, Christian König wrote:
> > 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.
> 
> Sure we can churn if we really want. But as 99% of callers will be 
> passing 0 it's not even very readable. Another option is variadic like 
> kmalloc_objs so flags can be optional. Anyway, for consideration only.


It has the advantage of forcing the reader to think about whether he
wants 64-bit sequence numbers or not. In Rust-fence, for example, we
completely overlooked that for months:

https://lore.kernel.org/rust-for-linux/20261023175750.2979015-2-phasta@xxxxxxxxxx/


Besides unused flags fields are quite common in APIs. As I state in the
description, this is also for future extensions, see my race-flag (if
accepted) as one potential example.

It could also be used for canonically setting the user-flags, which
users currently do with a manual set_bit(NR, &fence.base.flags;

So I think it's safe to say that it's the right thing for long-term
reduction of churn and maintainability.


P.