On Wed, 2024-12-04 at 13:12 +0000, Donald Hunter wrote: > My main motivation is coverage, for 2 reasons: firstly to flush out > any feature gaps in YNL such as the ones I fixed in this series Yeah, OK, though I'm not sure YNL is really meant to be feature complete for everything netlink may be doing, rather than for what's needed - and some of the things we did may even be things that are not meant to be done any more (e.g. nested array vs. multi-attr arrays.) > and > secondly to achieve a critical mass of YNL specs that encourages > people to build more tooling around the specs. OK, fair :) > YNL is already used for > in-tree test automation and documentation generation. There is > potential for generating strace dumpers and people are starting to use > generated user space code. Right. > > 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 ... 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 :) > > > + 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? johannes
