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... [1] https://github.com/Netronome/nfp-drv-kmods -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
