Re: [patch net-next v2] tools: ynl: introduce option to process unknown attributes or types

[Jiri Pirko <jiri@resnulli.us>]

Tue, Oct 17, 2023 at 05:50:53PM CEST, kuba@kernel.org wrote:
>On Tue, 17 Oct 2023 08:18:13 +0200 Jiri Pirko wrote:
>> Tue, Oct 17, 2023 at 02:59:03AM CEST, kuba@kernel.org wrote:
>> >On Mon, 16 Oct 2023 13:02:22 +0200 Jiri Pirko wrote:  
>> >> +class FakeSpecAttr:
>> >> +    def __init__(self, name):
>> >> +        self.dict = {"name": name, "type": None}
>> >> +        self.is_multi = False
>> >> +
>> >> +    def __getitem__(self, key):
>> >> +        return self.dict[key]
>> >> +
>> >> +    def __contains__(self, key):
>> >> +        return key in self.dict  
>> >
>> >Why the new class? Why not attach the NlAttr object directly?  
>> 
>> It's not NlAttr, it's SpecAttr. And that has a constructor with things I
>> cannot provide for fake object, that's why I did this dummy object.
>
>Just to be able to do spec["type"] on it?

Nope. Need .is_multi() and spec["name"] as well.

>
>There is an if "ladder", just replace the first
>
>	if attr_spec["type"] == ...
>
>with
>	if attr_spec is None:
>		# your code
>	elif attr_spec["type"] == ...
>
>hm?

Well, I need the same processing for "else".

Okay, I'll to this with local variables instead. Fake class looked a bit
more elegant.


>
>> >I have an idea knocking about in my head to support "polymorphic"
>> >nests (nests where decoding depends on value of another attr,
>> >link rtnl link attrs or tc object attrs). The way I'm thinking 
>> >about doing it is to return NlAttr / struct nla_attr back to the user.
>> >And let the users call a sub-parser of choice by hand.  
>> 
>> Sounds parallel to this patch, isn't it?
>
>I'm just giving you extra info to explain my thinking.
>Given how we struggle to understand each other lately :S

Yeah :/


>
>> >So returning a raw NlAttr appeals to me more.  
>> 
>> Wait, you suggest not to print out attr.as_bin(), but something else?
>
>Yea, it should not be needed. NlAttr has a __repr__ which *I think*
>should basically do the same thing? Or you may need to call that
>__repr__ from __str__, I don't know what PrettyPrinter uses internally


Instead of:
{'129': {'0': b'\x00\x00\x00\x00\x00\x00\x00\x00',
         '1': b'\x00\x00\x00\x00\x00\x00\x00\x00',
         '2': b'(\x00\x00\x00\x00\x00\x00\x00'},
You'd get:
{'129': {'0': [type:0 len:12] b'\x00\x00\x00\x00\x00\x00\x00\x00',
         '1': [type:1 len:12] b'\x00\x00\x00\x00\x00\x00\x00\x00',
         '2': [type:2 len:12] b'(\x00\x00\x00\x00\x00\x00\x00'},
Looks like unnecessary redundant info, I would rather stick with
"as_bin()". __repr__() is printable representation of the whole object,
we just need value here, already have that in a structured object.



>
>> >> +                if not self.process_unknown:
>> >> +                    raise Exception(f'Unknown {attr_spec["type"]} with name {attr_spec["name"]}')
>> >> +                if attr._type & Netlink.NLA_F_NESTED:
>> >> +                    subdict = self._decode(NlAttrs(attr.raw), None)
>> >> +                    decoded = subdict
>> >> +                else:
>> >> +                    decoded = attr.as_bin()  
>> >
>> >Again, I wouldn't descend at all.  
>> 
>> I don't care that much. I just thought it might be handy for the user to
>> understand the topology. Actually, I found it quite convenient already.
>> It's basically a direct dump. What is the reason not to do this exactly?
>
>No strong reason but you need to rewrite it to at least not access
>attr._type directly.

Okay.

>
>I have a weak preference for putting this code in NlAttr's __repr__,
>could be more broadly useful?

As I pointed out above, it's a different use case. Here we do decoding
into structured object. __repr__() is fro plain str conversion.