On Thu, 3 Sep 2020 07:57:29 +0200 Jiri Pirko wrote: > Wed, Sep 02, 2020 at 05:30:25PM CEST, k...@kernel.org wrote: > >On Wed, 2 Sep 2020 11:46:27 +0200 Jiri Pirko wrote: > >> >? Do we need such change there too or keep it as is, each action by itself > >> >and return what was performed ? > >> > >> Well, I don't know. User asks for X, X should be performed, not Y or Z. > >> So perhaps the return value is not needed. > >> Just driver advertizes it supports X, Y, Z and the users says: > >> 1) do X, driver does X > >> 2) do Y, driver does Y > >> 3) do Z, driver does Z > >> [ > >> I think this kindof circles back to the original proposal... > > > >Why? User does not care if you activate new devlink params when > >activating new firmware. Trust me. So why make the user figure out > >which of all possible reset option they should select? If there is > >a legitimate use case to limit what is reset - it should be handled > >by a separate negative attribute, like --live which says don't reset > >anything. > > I see. Okay. Could you please sum-up the interface as you propose it?
What I proposed on v1, pass requested actions as a bitfield, driver may perform more actions, we can return performed actions in the response. Then separate attribute to carry constraints for the request, like --live. I'd think the supported actions in devlink_ops would be fine as a bitfield, too. Combinations are often hard to capture in static data.
