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

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 26 Oct 2023 18:25:14 +0200 Jiri Pirko wrote:
> Thu, Oct 26, 2023 at 04:41:20PM CEST, kuba@kernel.org wrote:
> >On Thu, 26 Oct 2023 07:42:33 +0200 Jiri Pirko wrote:  
> >> {'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.
> >> 
> >> 
> >> What is "type" and "len" good for here?  
> >
> >I already gave you a longer explanation, if you don't like the
> >duplication, how about you stop keying them on a (stringified?!) id.  
> 
> I don't care that much, it just looks weird :)

As I said my key requirement is that the NlAttr object must still 
be there in the result.

Maybe a good compromise is to stick it into the key, instead of the
value. Replacing the stringified type id. Then you can keep the
value as binary. We'd need to wrap it into another class but whatever,
compromises.

IDK how this works in Python exactly but to give you a rough idea
here's pseudo code typed in the email client:

class UnknownNlAttrKey:
	def __init__(self, nlattr):
		self.nla = nlattr
	def __hash__(self):
		return self.nla.type
	def __eq__(self, other):
		if isintance(other, Unknown...):
			return other.nla.type == self.nla.type
		return False
	def __repr__():
		return f"UnknownAttr({self.nla.type})"