lists.openwall.net   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  linux-cve-announce  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:   Tue, 28 Jul 2020 13:19:50 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jacob Keller <jacob.e.keller@...el.com>
Cc:     Jakub Kicinski <kubakici@...pl>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Tom Herbert <tom@...bertland.com>,
        Jiri Pirko <jiri@...lanox.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Michael Chan <michael.chan@...adcom.com>,
        Bin Luo <luobin9@...wei.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Leon Romanovsky <leon@...nel.org>,
        Ido Schimmel <idosch@...lanox.com>,
        Danielle Ratson <danieller@...lanox.com>
Subject: Re: [RFC PATCH net-next v2 6/6] devlink: add overwrite mode to flash
 update

Mon, Jul 27, 2020 at 08:13:12PM CEST, jacob.e.keller@...el.com wrote:
>
>
>On 7/26/2020 12:16 AM, Jiri Pirko wrote:
>> Wed, Jul 22, 2020 at 05:30:05PM CEST, jacob.e.keller@...el.com wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: netdev-owner@...r.kernel.org <netdev-owner@...r.kernel.org> On
>>>> Visible in which sense? We don't show components anywhere if I'm not
>>>> mistaken. They are currently very rarely used. Basically we just ported
>>>> it from ethtool without much thinking.
>>>>
>>>
>>> Component names are used in devlink info and displayed to end users along with versions, plus they're names passed by the user in devlink flash update. As far as documented, we shouldn't add new components without associated versions in the info report.
>> 
>> Okay. So it is loosely coupled. I think it would be nice to tight those
>> 2 togeter so it is not up to the driver how he decides to implement it.
>> 
>I felt the coupling was quite clear from Jakub's recent documentation
>improvements in the devlink-flash.rst doc file.
>
>Are you thinking find some way to tie these two lists more closely in code?

Yes. Documentation is very easy to ignore unfortunatelly. The driver
developer has to be tight up by the core code and api, I believe.

>
>Thanks,
>Jake

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ