netdev - Re: [RFC PATCH net-next v2 6/6] devlink: add overwrite mode to flash update

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]

Message-ID: <20200728100939.108f33f0@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Tue, 28 Jul 2020 10:09:39 -0700
From:   Jakub Kicinski <kubakici@...pl>
To:     Jacob Keller <jacob.e.keller@...el.com>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        "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

On Tue, 28 Jul 2020 09:58:44 -0700 Jacob Keller wrote:
> On 7/28/2020 4:19 AM, Jiri Pirko wrote:
> > Yes. Documentation is very easy to ignore unfortunatelly. The driver
> > developer has to be tight up by the core code and api, I believe.
>
> So I'm not sure what the best proposal here is. We do have a list of
> generic components, but given that each piece of HW has different
> elements, it's not always feasible to have fully generic names. Some of
> the names are driver specific.
> 
> I guess we could use some system where components are "registered" when
> loading the devlink, so that they can be verified by the stack when used
> as a parameter for flash update? Perhaps take something like the
> table-driven approach used for infos and extend that into devlink core
> so that drivers basically register a table of the components which
> includes both a function callback that gets the version string as well
> as an indication of whether that component can be updated via flash_update?
> 
> I know it would also be useful for ice to have a sort of "pre-info"
> callback that generates a context structure that is passed to each of
> the info callbacks. (that way a single up-front step could be to lookup
> the relevant information, and this is then forwarded to each of the
> formatter functions for each component).
> 
> Am I on the right track here or just over-engineering?

I don't understand why we're having this conversation.

No driver right now uses the component name.

AFAIU we agreed not to use the component name for config vs code.

So you may as well remove the component name from the devlink op and
add a todo there saying "when adding component back, make sure it's
tightly coupled to info".