net80211: add IEEE80211_IOC_DEVCAPS2, include versioned responses

[adrian]

Summary

• Handle an ioctl req with i_val == IEEE80211_DEVCAPS_VERSION_1 as a versioned response (version 1.)

• Version 1 includes a bunch of new fields and (hopefully!) later 802.11 support (11ax, 11be, 11bn) so we don't have to add them later.

• It also includes 64 bit fields rather than 32 bit fields, primarily as we're about to run out of devcap bitfields and it's about time we expanded it to 64 bits.

This should be both forwards and backwards compatible:

• older wpa_supplicant w/ newer net80211 will always request IEEE80211_IOC_DEVCAPS w/ i_val == 0, so it'll return the existing API.

• newer wpa_supplicant w/ older net80211 will request IEEE80211_IOC_DEVCAPS2 w/ i_val > 0, fail the ioctl, and can fall back to the original ioctl.

[adrian]

update diff url

[adrian]

address comments

[emaste]

sys/net80211/ieee80211_ioctl.c

1156–1158

Is the intent that we'd remove this "eventually"? E.g. if in 15.x we're normally using DEVCAPS2 we could probably remove this once 14.x goes past EOL.

sys/net80211/ieee80211_ioctl.h

572

We should avoid "new" since it will quickly become "current" and then "old" :)

It's a little confusing that this is devcaps2 / version 1 though so I'm not sure of great terminology.

[imp]

sys/net80211/ieee80211_ioctl.c

1157

I'd add a fires once printf here.

[bz]

sys/net80211/ieee80211_ioctl.c

767

Already breaks the naming between left and right; that's what I meant above.

sys/net80211/ieee80211_ioctl.h

579

I think having done the change from jail_v1 to jail_v2 I was happy no one ever really did a jail_v3 struct; the pain is high. I don't think this is thought to an end but has the thinking we had 15 years ago.

591

So vht_cap_info can never be more than uint32_t right? Are we going to overload the same field with other bits?

592

What a weird order... HE before EHT.

But I really dislike keeping going with this gazillions of bitflags and unnamed options and #defines. They are a pain. I would have hoped if we change the thing to something new we'd be more clever (especially given almost all of these bits can be named and are known).

721

"old" soon is the new "old old"

740

New soon is the new old ... oh as Ed said above; just seen that now.

[imp]

Would nv lists be better?

[adrian]

sys/net80211/ieee80211_ioctl.h

572

We should avoid "new" since it will quickly become "current" and then "old" :)

It's a little confusing that this is devcaps2 / version 1 though so I'm not sure of great terminology.

I'm open to alternative suggestions here.

The challenge is there's no guaranteed correct way to use the existing DEVCAPS ioctl, so without renaming it to DEVCAPSOLD or something, we need to name it /something/.

If people don't mind breaking the ABI during 15/current then we don't need the old code, we can just start migrating the APIs over to versioned representations or whatever else people would like as an intermediary step.

592

I'm open to suggestions for alternate representation of capabilities!

[bz]

sys/net80211/ieee80211_ioctl.h

592

struct and name them. bools are bits which give names. Works in 2024. Didn't in 2004 most likely in the kernel. Try to not invent new names, especially if the structs are already present in src/sys/ somewhere.

[adrian]

sys/net80211/ieee80211_ioctl.h

592

That's the current problem though - the current capabilities aren't all structs, a lot of them are still bitfields. I see you've converted a couple of them? But there's still a lot of work to do.