On 11/5/26 13:48, Philipp Stanner wrote: > -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?
I was considering to invert the flag meaning, e.g. have SEQNO32 instead of SEQNO64. But as I recently learned even on brand new x86 Intel CPUs you can do non 64bit aligned 64bit writes (yeah x86 architecture!) and PCIe devices see that as two 32bit writes to system memory which might or might not read coherently. So assuming all future HW will be 64bit is clearly not possible. >> >> 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. Yeah I'm largely in favor of that as well. Regards, Christian. > > > P.
