-----Original Message-----
From: Jakub Kicinski <kuba@kernel.org>
Sent: Monday, July 25, 2022 12:39 PM
To: Keller, Jacob E <jacob.e.keller@intel.com>
Cc: Jiri Pirko <jiri@resnulli.us>; netdev@vger.kernel.org
Subject: Re: [net-next PATCH 1/2] devlink: add dry run attribute to flash update

On Mon, 25 Jul 2022 19:15:10 +0000 Keller, Jacob E wrote:

quoted

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.

Its probably worth fixing policy, but would like to come up with a proper path that doesn't break compatibility and that will require discussion to figure out what approach works.

I'll remove the comment though since this problem affects all attributes.

Thanks,
Jake