netdev - Re: [for-next 5/6] net/mlx5: Bump driver version

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170526145318.7fd8c8e2@cakuba.netronome.com>
Date:   Fri, 26 May 2017 14:53:18 -0700
From:   Jakub Kicinski <kubakici@...pl>
To:     Dennis Dalessandro <dennis.dalessandro@...el.com>
Cc:     Saeed Mahameed <saeedm@....mellanox.co.il>,
        Saeed Mahameed <saeedm@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>,
        Doug Ledford <dledford@...hat.com>,
        Linux Netdev List <netdev@...r.kernel.org>,
        linux-rdma@...r.kernel.org, Ilan Tayari <ilant@...lanox.com>,
        Tariq Toukan <tariqt@...lanox.com>
Subject: Re: [for-next 5/6] net/mlx5: Bump driver version

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