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