Grant Grundler <grundler@xxxxxxxxxx> writes: > Sorry for the late response...just one point below > > On Fri, Nov 20, 2015 at 3:22 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> > wrote: > > > +#define MWL_DRV_NAME KBUILD_MODNAME > > +#define MWL_DRV_VERSION "10.3.0.14" > > versions like that are generally fairly useless since you don't update > them for every commit ... > > > When backporting to other kernel trees, it's extremely handy to have a > DRV_VERSION. > > Checking if a particular kernel build has the expected driver version trivial. > "mod_info" dumps the driver version for modules (which this will usually be > too). > > And yes, it won't get updated for every commit only because other version > control might encapsulate those changes. Not every distro makes their build > versioning accessible to outsiders. So it's still helpful even if not perfect. > > Marvell can update this every time they resync with their own internal > versions. But the problem is that you cannot really trust this driver version string. I found a perfect example from another Marvell driver: 5e6e3a92b9a4c drivers/net/wireless/mwifiex/main.c (Bing Zhao 2011-03-21 18:00:50 -0700 25) #define VERSION "1.0" So nobody has updated that version string since the initial commit from 2011 and that driver has had over 900 non-merge commits after that. Because of bad cases like this I think having a driver specific versions in in-tree drivers are just noise and unnecessary extra work. When porting a driver to another tree git commit ids, release tag names or git-describe output are much better ways to identify the driver version. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
