From: Jiri Pirko <jiri@resnulli.us>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org, pabeni@redhat.com, davem@davemloft.net,
edumazet@google.com
Subject: Re: [patch net-next v3] tools: ynl: introduce option to process unknown attributes or types
Date: Fri, 27 Oct 2023 10:36:51 +0200 [thread overview]
Message-ID: <ZTt2o294RMW+MwKs@nanopsycho> (raw)
In-Reply-To: <20231026123058.140072c7@kernel.org>
Thu, Oct 26, 2023 at 09:30:58PM CEST, kuba@kernel.org wrote:
>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.
Yeah, that I don't how to do honestly. See below.
>
>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.
Okay, that sounds good. But "key": \bvalue is not something to be
printed out by __repr__() as it outs string. Therefore I don't
understand how this compiles with your key requirement above.
I have to be missing something, pardon my ignorance.
>We'd need to wrap it into another class but whatever,
>compromises.
Will check on how to implement this.
>
>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})"
I see, will check if this is needed.
next prev parent reply other threads:[~2023-10-27 8:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-25 9:57 [patch net-next v3] tools: ynl: introduce option to process unknown attributes or types Jiri Pirko
2023-10-26 0:56 ` Jakub Kicinski
2023-10-26 5:42 ` Jiri Pirko
2023-10-26 14:41 ` Jakub Kicinski
2023-10-26 14:46 ` Jakub Kicinski
2023-10-26 16:24 ` Jiri Pirko
2023-10-26 16:25 ` Jiri Pirko
2023-10-26 19:30 ` Jakub Kicinski
2023-10-27 8:36 ` Jiri Pirko [this message]
2023-10-27 14:08 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZTt2o294RMW+MwKs@nanopsycho \
--to=jiri@resnulli.us \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).