netdev - Re: [PATCH net-next 5/5] net: aquantia: bump driver version

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: <11799a46-9f2f-3d2b-1671-8910a951e539@aquantia.com>
Date:   Sun, 12 Aug 2018 10:53:23 +0300
From:   Igor Russkikh <igor.russkikh@...antia.com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        Simon Edelhaus <simon.edelhaus@...antia.com>
Subject: Re: [PATCH net-next 5/5] net: aquantia: bump driver version

>> Hope the above are good enough arguments to keep up version bumps.
> 
> A reasonably successful strategy is to version your out-of-tree driver
> with corresponding kernel release versions.  Flip the equation.
> 
> E.g. current net-next will become 4.19, so all the features you're
> pushing now would in your GH repo be:
> 
> 4.19.0.${extra_numbers_if_you_want}-gh
> 
> And you still have single versioning scheme, but the "bump to version
> XYZ" commits now go into your local tree not the kernel.
> 
> As Andrew said backports make driver versions less than useful.  Not
> only feature backports to enterprise kernel, but bug fixes which have to
> go to stable.
> 

Technically yes, thats a good and manageable suggestion.

However the problem here is a human factor.

Regular users are often aware that NIC drivers are regularly
get updates, fixes etc. And they logically assume there is a
driver version in there. And what user normally does first
time he/she buys new NIC is checking driver version in system.

Obviously what user use is `ethtool -i` since thats a documented and
the only user visible tool.

What we'll get here is totally uncorrelated versioning info between inkernel
driver (some ancient version or no version at all) and vendor driver.

This will confuse user as he/she will start thinking (for example) that his
in kernel driver is "bad" and has to be updated.

Another human factor is tech support personnel, who also expect NIC drivers
to have version. We'll get tons of requests sort of "why and when you'll update
your upstream driver". It is up to date. "But why its version is not updated then?"

A lot of technical reports from fields does not include kernel version, but
(since users talk about NIC) just an "ethtool -i" output. This'll confuse us
as we have to do more queries on kernel version.

These are all legitimate expectations from non-tech people and what we trying
to do now is to keep up inkernel versioning with our local versioning.

Thus, user now sees:

version: 2.0.3.0-kern (for inkernel driver)
or
version: 2.0.6.0 (for external driver)

and can at least judge whether he needs updates or if thats OK.

As a one liner sumup:
kernel have user visible 'ethtool -i' API. Why should we drop it and deprecate it?

BR, Igor