[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180809122048.3f2d0938@cakuba.netronome.com>
Date: Thu, 9 Aug 2018 12:20:48 -0700
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: Igor Russkikh <igor.russkikh@...antia.com>
Cc: Andrew Lunn <andrew@...n.ch>,
"David S . Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 5/5] net: aquantia: bump driver version
On Thu, 9 Aug 2018 13:10:09 +0300, Igor Russkikh wrote:
> 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.
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.
Powered by blists - more mailing lists