Re: [PATCH net-next v5 10/10] netlink: specs: wireless: add a spec for nl80211

[Johannes Berg <johannes@sipsolutions.net>]

On Sat, 2025-05-03 at 13:07 -0700, Jakub Kicinski wrote:
> Looks like we have 3 structs in the Netlink spec:
>  - ieee80211-ht-cap
>  - ieee80211-mcs-info
>  - ieee80211-vht-mcs-info
> which are defined in include/linux/ieee80211.h rather than the uAPI,
> but we do use them in Netlink attrs. I'm guessing these come from 
> the IEEE spec so there is no ambiguity?

Yes. In some of these cases userspace has different definitions that
match the same bits, but might have e.g. __le32 vs. u8 for some fields
and then just has a different number of fields. For HT it looks pretty
similar though.

Certainly there are many more in this area that could have a similar
situation. There are also new ones where there's maybe not a good struct
representation at all, unless you care only about special cases (which
may well be appropriate for some tools, but not for the API.)

> I'm trying to figure out what to do with them in the C codegen
> for YNL. Normally we assume all structs used by the spec are defined
> in the headers. We can add an annotation to render the definition
> in user space code, but I wonder if this omission is really intentional?
> Wouldn't it be generally useful to user space to expose the types 
> in uAPI?

We never even conceptually exposed these in the original nl80211.h, that
just literally said it's the HT capability element, without caring how
you arrived at the bytes representing it. We did define the length for
the policy check, but I guess in some way even that isn't needed.

I'm not really sure it really is all that useful given that different
tools care about different things and restrictions (endian, etc.).

I also don't know if we'd really want the kernel to become the canonical
definition of structures used for elements defined in the spec., but
then is it restricted to those that need to be in the userspace API?
That would also feel a bit odd?

So not sure. I'd almost prefer to just remove the struct annotation from
the spec here.

johannes