On Fri, May 26, 2017 at 02:53:18PM -0700, Jakub Kicinski wrote: > On Fri, 26 May 2017 12:55:22 -0400, Dennis Dalessandro wrote: > > >> I realize Dave has already pulled this and I'm not asking for it to be > > >> reverted but maybe some discussion will help guide future patch submissions > > >> which do this stuff. > > >> > > > > > > Sure, although i don't think we are going to use those version fields > > > in the future, > > > please allow me to ask, how do you do your driver versioning ? how do > > > you track things ? > > > and what is your future vision regarding ethool->drv_version ? > > > > That's just the thing, we don't do anything with it either really. I'm > > trying to justify its existence to myself and if you folks had some whiz > > bang idea for a driver version I was interested in hearing what it was. > > FWIW I put VERMAGIC_STRING in drv_version: > > # ethtool -i p4p1 > driver: nfp > version: 4.12.0-rc2-perf-00282-gc42dfc79 > ... > > I think I got that idea from Felix Fietkau. The backport-ified version > of the driver [1] uses git hash and "o-o-t" sting: > > # ethtool -i p4p1 > driver: nfp > version: 49e5c6abf5b2 (o-o-t) > ... > > So it's pretty easy to tell which driver the customer is using. I > could probably throw in the output of $(git rev-list --count HEAD) to > have an automatic monotonically increasing "version" when built > out-of-tree, hm... Thanks for the pointer. I'll try to evaluate it. > > [1] https://github.com/Netronome/nfp-drv-kmods
Attachment:
signature.asc
Description: PGP signature
