netdev - Re: [PATCH net-next 01/11] devlink: add macro for "drv.spec"

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] [day] [month] [year] [list]

Message-ID: <20200318191427.20b1ec5f@kicinski-fedora-PC1C0HJN>
Date:   Wed, 18 Mar 2020 19:14:27 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Michael Chan <michael.chan@...adcom.com>
Cc:     Jacob Keller <jacob.e.keller@...el.com>,
        Vasundhara Volam <vasundhara-v.volam@...adcom.com>,
        David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>, Jiri Pirko <jiri@...lanox.com>
Subject: Re: [PATCH net-next 01/11] devlink: add macro for "drv.spec"

On Wed, 18 Mar 2020 17:47:26 -0700 Michael Chan wrote:
> On Wed, Mar 18, 2020 at 5:05 PM Jacob Keller <jacob.e.keller@...el.com> wrote:
> > On 3/18/2020 1:04 PM, Jakub Kicinski wrote:  
> > > We're just getting rid of driver versions, with significant effort,
> > > so starting to extend devlink info with driver stuff seems risky.
> > > How is driver information part of device info in the first place?
> > >
> > > As you said good driver and firmware will be modular and backward
> > > compatible, so what's the meaning of the API version?
> > >
> > > This field is meaningless.
> >
> > I think I agree with Jakub here. I assume, if it's anything like what
> > the ice driver does, the firmware has an API field used to communicate
> > to the driver what it can support. This can be used by the driver to
> > decide if it can load.
> >
> > For example, if the major API number increases, the ice driver then
> > assumes that it must be a very old driver which will not work at all
> > with that firmware. (This is mostly kept as a safety hatch in case no
> > other alternative can be determined).
> >
> > The driver can then use this API number as a way to decide if certain
> > features can be enabled or not.
> >
> > I suppose printing the driver's "expected" API number makes sense, but I
> > think the stronger approach is to make the driver able to interoperate
> > with any previous API version. Newer minor API numbers only mean that
> > new features exist which the driver might not be aware of. (for example,
> > if you're running an old driver).
> 
> Agreed.  Our driver is backward and forward compatible with all
> production firmware for the most part.  The idea is that the effective
> API version number is the minimum of the driver's API and firmware's
> API.  For example, if firmware is at v1.5 and driver is at v1.4, then
> the effective or operating API is v1.4.  The new features after v1.4
> are unused because the driver does not understand those new features.
> Similarly, a newer driver running on older firmware will have the
> older firmware's API as the effective API.  The driver will not use
> the new features that the firmware doesn't understand.
> 
> So if there is only one API version to report, reporting the min.
> makes the most sense to the user in our case.  It is similar to a Gen4
> PCIe card currently operating in a Gen3 slot.

Sounds reasonable.