On Wed, 4 Dec 2024 at 13:28, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > > > Also, I don't know how we will maintain this if it's not tied to any > > > kernel code. What do you suggest? Do you want to just maintain it > > > following the nl80211.h spec all the time? > > > > It's a good question. I am okay with maintaining it alongside the > > nl80211.h file, which will likely motivate me to write some automation > > at least for notifying any divergence. There might come a time when it > > becomes desirable to generate some of nl80211.h from the spec, as > > Stanislav Fomichev is doing for ethtool here: > > > > https://lore.kernel.org/netdev/20241202162936.3778016-1-sdf@xxxxxxxxxxx/ > > I think I wouldn't mind that - I'm hoping it'll also generate policies > etc.? Though on that front we probably have weird quirks too ... Yes, the policies are generated, quirks notwithstanding ;-) > But until then I guess someone's going to have to maintain it, and I'm > not sure I want that to be me right now :) Ack that. The burden is on me. > > > > + name: get-wiphy > > > > + doc: Get information about a wiphy or dump a list of all wiphys > > > > + attribute-set: nl80211-attrs > > > > + do: > > > > + request: > > > > + value: 1 > > > > + attributes: > > > > + - wiphy > > > > + reply: > > > > + value: 3 > > > > + dump: > > > > + request: > > > > + attributes: > > > > + - wiphy > > > > > > > > > > This already seems wrong - dump wiphy really should unconditionally > > > include NL80211_ATTR_SPLIT_WIPHY_DUMP these days. > > > > Yes, the valid parameter attributes should be wiphy, wdev, ifindex and > > split-wiphy-dump by the look of it. > > Well there's that about valid parameters, but also no (new) tools today > should ever *not* include the split-wiphy-dump attribute. I guess that > can't be expressed here, but it's a gotcha for implementers that just > follow the YNL spec? There's no way to specify that, but the constraint can be described clearly in the doc string. I'll do that for v2. Thanks, Donald.
