[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231026123058.140072c7@kernel.org>
Date: Thu, 26 Oct 2023 12:30:58 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: netdev@...r.kernel.org, pabeni@...hat.com, davem@...emloft.net,
edumazet@...gle.com
Subject: Re: [patch net-next v3] tools: ynl: introduce option to process
unknown attributes or types
On Thu, 26 Oct 2023 18:25:14 +0200 Jiri Pirko wrote:
> Thu, Oct 26, 2023 at 04:41:20PM CEST, kuba@...nel.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})"
Powered by blists - more mailing lists