Re: [PATCH net-next v2 3/6] tools: ynl: Add array-nest attr decoding to ynl

[Jakub Kicinski <kuba@kernel.org>]

On Sun, 19 Mar 2023 19:38:00 +0000 Donald Hunter wrote:
> Add support for decoding nested arrays of scalars in netlink messages.

example?

> Signed-off-by: Donald Hunter <donald.hunter@gmail.com>
> ---
>  tools/net/ynl/lib/ynl.py | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tools/net/ynl/lib/ynl.py b/tools/net/ynl/lib/ynl.py
> index 32536e1f9064..077ba9e8dc98 100644
> --- a/tools/net/ynl/lib/ynl.py
> +++ b/tools/net/ynl/lib/ynl.py
> @@ -93,6 +93,10 @@ class NlAttr:
>      def as_bin(self):
>          return self.raw
>  
> +    def as_array(self, type):
> +        format, _ = self.type_formats[type]
> +        return list({ x[0] for x in struct.iter_unpack(format, self.raw) })

So in terms of C this treats the payload of the attr as a packed array?
That's not what array-nest is, array-nest wraps every entry in another
nlattr:
https://docs.kernel.org/next/userspace-api/netlink/genetlink-legacy.html#array-nest

It's not a C array dumped into an attribute.

IIRC I was intending to use 'binary' for packed arrays. Still use
sub-type to carry the type, but main type should be 'binary'.

If that sounds reasonable could you document or remind me to document
this as the expected behavior? Sub-type appears completely undocumented
now :S

>      def __repr__(self):
>          return f"[type:{self.type} len:{self._len}] {self.raw}"
>  
> @@ -381,6 +385,8 @@ class YnlFamily(SpecFamily):
>                  decoded = attr.as_bin()
>              elif attr_spec["type"] == 'flag':
>                  decoded = True
> +            elif attr_spec["type"] == 'array-nest':
> +                decoded = attr.as_array(attr_spec["sub-type"])
>              else:
>                  raise Exception(f'Unknown {attr.type} {attr_spec["name"]} {attr_spec["type"]}')
>