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

Date:   Wed, 18 Mar 2020 17:47:26 -0700
From:   Michael Chan <michael.chan@...adcom.com>
To:     Jacob Keller <jacob.e.keller@...el.com>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        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, 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.

Thanks.