[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a409e532-035e-3544-a050-e7238f3a45f4@aquantia.com>
Date: Thu, 9 Aug 2018 13:10:09 +0300
From: Igor Russkikh <igor.russkikh@...antia.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: "David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 5/5] net: aquantia: bump driver version
Hi Andrew,
Thanks for the review, agreed on all your findings,
we'll address these comments in next version.
> Driver versions are pretty much useless. Say somebody backports this
> driver into a vendor kernel. Vendor kernels are typically based on an
> old kernel, plus thousands of patches. Is 2.0.4 on such a kernel the
> same as 2.0.4 in 4.19?
>
> You probably want to remove this, just the avoid people thinking is
> means something.
We do distribute our driver as a separate source package, customers for older
kernels use it and install without updating their kernels.
We also in fact always have a gap in featureset between upstream driver and our
preview driver releases on github - alot of people tend to tryout 'hot and latest' driver
instead of waiting for their distro kernel to receive updates.
All this means we have to understand which version (and featureset) users have installed in fields.
`ethtool -i` and this internal driver version is a huge helper for us.
You are right that in event of backporting there could be some uncertainty whether that bugfix is there or not.
But having kernel version plus driver version really helps us to understand the exact configuration in fields.
Moreover, inkernel driver version bumps are linked with new features added (like in this patchset).
Thus the overall concept of internal version is still very useful for Aquantia technical and support engineers.
Hope the above are good enough arguments to keep up version bumps.
BR, Igor
Powered by blists - more mailing lists