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/[email protected]/ 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.
