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] [day] [month] [year] [list]
Message-ID: <20250503130739.1c94d433@kernel.org>
Date: Sat, 3 May 2025 13:07:39 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Johannes Berg <johannes@...solutions.net>
Cc: Donald Hunter <donald.hunter@...il.com>, netdev@...r.kernel.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 v5 10/10] netlink: specs: wireless: add a spec
 for nl80211

On Tue, 11 Feb 2025 12:01:27 +0000 Donald Hunter wrote:
> +    name: ieee80211-mcs-info
> +    type: struct
> +    members:
> +      -
> +        name: rx-mask
> +        type: binary
> +        len: 10
> +      -
> +        name: rx-highest
> +        type: u16
> +        byte-order: little-endian
> +      -
> +        name: tx-params
> +        type: u8
> +      -
> +        name: reserved
> +        type: binary
> +        len: 3

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?

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?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ