Re: [PATCH rdma-next] RDMA/mana_ib: Retain create CQ flags field name

On Tue, Aug 04, 2026 at 01:08:18PM +0200, Jiri Pirko wrote:
> Mon, Aug 03, 2026 at 03:28:44PM +0200, [email protected] wrote:
> >On Mon, Aug 03, 2026 at 01:59:07PM +0200, Jiri Pirko wrote:
> >> Fri, Jul 31, 2026 at 02:54:31PM +0200, [email protected] wrote:
> >> >> From: Jiri Pirko <[email protected]>
> >> >> 
> >> >> Commit eb70d83a8645 ("RDMA/mana_ib: Adopt robust udata") renamed the
> >> >> "flags" field of struct mana_ib_create_cq to "comp_mask", as
> >> >> ib_copy_validate_udata_in_cm() only validates a member with that name.
> >> >> 
> >> >> The layout did not change, but the field has been a part of the UAPI since
> >> >> commit 44b607ad4cdf ("RDMA/mana_ib: implement uapi for creation of rnic
> >> >> cq"), so the rename breaks userspace referring to it, for example the mana
> >> >> provider of rdma-core assigning cmd_drv->flags.
> >> >> 
> >> >> Convert the field to a union providing both names, so that
> >> >> ib_copy_validate_udata_in_cm() still finds "comp_mask" and userspace keeps
> >> >> "flags", without having to add a helper for this single case.
> >> >> 
> >> >
> >> >Thanks for the patch, but my understanding that it is a common practice to rename the fields,
> >> >and kernels headers should not accumulate historical names. 
> >> 
> >> That is not doable in UAPI.
> >
> >There are multiple levels of UAPI contracts. In RDMA, we guarantee
> >binary compatibility because userspace (rdma-core) is effectively the
> >second half of the RDMA driver stack. These drivers do not exist
> >without rdma-core.
> >
> >As such, this is exactly how the RDMA UAPI is intended to work.
> 
> That is some odd UAPI...

It is not about UAPI itself, but about the rules governing it. The
rule is "don't break userspace"; it does not say "don't break the
build". The latter primarily affects advanced users, who are expected
to be capable of resolving build failures.

Thanks