netdev - Re: [PATCH net-next v1 7/7] netlink: specs: wireless: add a spec for nl80211

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAD4GDZxa-=_8DcVjz+=AQAyyiORey2U2sv6qmayoF34nTTN_cA@mail.gmail.com>
Date: Wed, 4 Dec 2024 14:08:36 +0000
From: Donald Hunter <donald.hunter@...il.com>
To: Johannes Berg <johannes@...solutions.net>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, linux-wireless@...r.kernel.org, 
	donald.hunter@...hat.com
Subject: Re: [PATCH net-next v1 7/7] netlink: specs: wireless: add a spec for nl80211

On Wed, 4 Dec 2024 at 13:28, Johannes Berg <johannes@...solutions.net> 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@fomichev.me/
>
> 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.