netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: "Keller, Jacob E" <jacob.e.keller@intel.com>
Cc: Jiri Pirko <jiri@resnulli.us>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [net-next PATCH 1/2] devlink: add dry run attribute to flash update
Date: Mon, 25 Jul 2022 12:39:17 -0700	[thread overview]
Message-ID: <20220725123917.78863f79@kernel.org> (raw)
In-Reply-To: <SA2PR11MB5100E125B66263046B322DC1D6959@SA2PR11MB5100.namprd11.prod.outlook.com>

On Mon, 25 Jul 2022 19:15:10 +0000 Keller, Jacob E wrote:
> I'm not sure exactly what the process would be here. Maybe something
> like:
> 
> 1. identify all of the commands which aren't yet strict
> 2. introduce new command IDs for these commands with something like
> _STRICT as a suffix? (or something shorter like _2?) 3. make all of
> those commands strict validation..
> 
> but now that I think about that, i am not sure it would work. We use
> the same attribute list for all devlink commands. This means that
> strict validation would only check that its passed existing/known
> attributes? But that doesn't necessarily mean the kernel will process
> that particular attribute for a given command does it?
> 
> Like, once we introduce DEVLINK_ATTR_DRY_RUN support for flash, if we
> then want to introduce it later to something like port splitting.. it
> would be a valid attribute to send from kernels which support flash
> but would still be ignored on kernels that don't yet support it for
> port splitting?
> 
> Wouldn't we want each individual command to have its own validation
> of what attributes are valid?
> 
> I do think its probably a good idea to migrate to strict mode, but I
> am not sure it solves the problem of dry run. Thoughts? Am I missing
> something obvious?
> 
> Would we instead have to convert from genl_small_ops to genl_ops and
> introduce a policy for each command? I think that sounds like the
> proper approach here....

...or repost without the comment and move on. IDK if Jiri would like 
to see the general problem of attr rejection solved right now but IMHO
it's perfectly fine to just make the user space DTRT.

  reply	other threads:[~2022-07-25 19:39 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-20 18:34 [net-next PATCH 0/2] devlink: implement dry run support for flash update Jacob Keller
2022-07-20 18:34 ` [net-next PATCH 1/2] devlink: add dry run attribute to " Jacob Keller
2022-07-21  5:54   ` Jiri Pirko
2022-07-21 20:32     ` Keller, Jacob E
2022-07-22  6:18       ` Jiri Pirko
2022-07-22 21:12         ` Keller, Jacob E
2022-07-23 15:42           ` Jiri Pirko
2022-07-25 19:15             ` Keller, Jacob E
2022-07-25 19:39               ` Jakub Kicinski [this message]
2022-07-25 20:27                 ` Keller, Jacob E
2022-07-25 20:32                   ` Jakub Kicinski
2022-07-25 20:46                     ` Keller, Jacob E
2022-07-26  1:13                       ` Jakub Kicinski
2022-07-26 17:23                         ` Keller, Jacob E
2022-07-26 18:48                           ` Jakub Kicinski
2022-07-26 18:49                             ` Keller, Jacob E
2022-07-26 18:21                         ` Keller, Jacob E
2022-08-05 16:32                         ` Keller, Jacob E
2022-08-05 18:51                           ` Jakub Kicinski
2022-08-05 19:50                             ` Keller, Jacob E
2022-07-25 20:33                   ` Keller, Jacob E
2022-07-21 16:47   ` Jakub Kicinski
2022-07-21 18:57     ` Keller, Jacob E
2022-07-21 16:48   ` Jakub Kicinski
2022-07-21 18:57     ` Keller, Jacob E
2022-07-20 18:34 ` [net-next PATCH 2/2] ice: support dry run of a flash update to validate firmware file Jacob Keller
2022-07-21  5:56   ` Jiri Pirko
2022-07-21 18:57     ` Keller, Jacob E
2022-07-21  7:53   ` Leon Romanovsky
2022-07-21  5:57 ` [net-next PATCH 0/2] devlink: implement dry run support for flash update 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=20220725123917.78863f79@kernel.org \
    --to=kuba@kernel.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jiri@resnulli.us \
    --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;
as well as URLs for NNTP newsgroup(s).