lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 2 Sep 2020 08:30:25 -0700
From:   Jakub Kicinski <>
To:     Jiri Pirko <>
Cc:     Moshe Shemesh <>,
        Moshe Shemesh <>,
        "David S. Miller" <>,
        Jiri Pirko <>,,
Subject: Re: [PATCH net-next RFC v3 01/14] devlink: Add reload action option
 to devlink reload command

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

Powered by blists - more mailing lists