public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org
Subject: Re: ynl - mutiple policies for one nested attr used in multiple cmds
Date: Sat, 5 Aug 2023 08:33:28 +0200	[thread overview]
Message-ID: <ZM3tOOHifjFQqorV@nanopsycho> (raw)
In-Reply-To: <20230804125816.11431885@kernel.org>

Fri, Aug 04, 2023 at 09:58:16PM CEST, kuba@kernel.org wrote:
>On Fri, 4 Aug 2023 19:29:31 +0200 Jiri Pirko wrote:
>> I need to have one nested attribute but according to what cmd it is used
>> with, there will be different nested policy.
>> 
>> If I'm looking at the codes correctly, that is not currenly supported,
>> correct?
>> 
>> If not, why idea how to format this in yaml file?
>
>I'm not sure if you'll like it but my first choice would be to skip
>the selector attribute. Put the attributes directly into the message.
>There is no functional purpose the wrapping serves, right?

Well, the only reason is backward compatibility.
Currently, there is no attr parsing during dump, which is ensured by
GENL_DONT_VALIDATE_DUMP flag. That means if user passes any attr, it is
ignored.

Now if we allow attrs to select, previously ignored attributes would be
processed now. User that passed crap with old kernel can gen different
results with new kernel.

That is why I decided to add selector attr and put attrs inside, doing
strict parsing, so if selector attr is not supported by kernel, user
gets message back.

So what do you suggest? Do per-dump strict parsing policy of root
attributes serving to do selection?

  reply	other threads:[~2023-08-05  6:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-04 17:29 ynl - mutiple policies for one nested attr used in multiple cmds Jiri Pirko
2023-08-04 19:58 ` Jakub Kicinski
2023-08-05  6:33   ` Jiri Pirko [this message]
2023-08-07 17:03     ` Jakub Kicinski
2023-08-07 17:12       ` Jiri Pirko
2023-08-07 17:24         ` Jakub Kicinski
2023-08-08  7:38           ` Jiri Pirko
2023-08-18  8:37   ` Jiri Pirko
2023-08-18 15:55     ` Jakub Kicinski
2023-08-18 18:11       ` Jiri Pirko
2023-08-18 20:24         ` Jakub Kicinski
2023-08-21 11:16           ` Jiri Pirko

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=ZM3tOOHifjFQqorV@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    /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