linux-kernel - Re: [PATCH 4/4] GenWQE: Increase driver version number

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 06 Jun 2014 14:07:33 +0200
From:	Frank Haverkamp <haver@...ux.vnet.ibm.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Kleber Sacilotto de Souza <klebers@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, haver@...ux.vnet.ibm.com
Subject: Re: [PATCH 4/4] GenWQE: Increase driver version number

Hi Greg,

Am Donnerstag, den 05.06.2014, 09:00 -0700 schrieb Greg KH:
> On Thu, Jun 05, 2014 at 11:23:04AM +0200, Frank Haverkamp wrote:
> > Hi Greg,
> > 
> > Am Mittwoch, den 04.06.2014, 08:54 -0700 schrieb Greg KH:
> > > On Wed, Jun 04, 2014 at 10:57:53AM -0300, Kleber Sacilotto de Souza wrote:
> > > > Increase genwqe driver version number.
> > > > 
> > > > Signed-off-by: Kleber Sacilotto de Souza <klebers@...ux.vnet.ibm.com>
> > > > ---
> > > >  drivers/misc/genwqe/genwqe_driver.h |    2 +-
> > > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/drivers/misc/genwqe/genwqe_driver.h b/drivers/misc/genwqe/genwqe_driver.h
> > > > index cd52631..a506e9a 100644
> > > > --- a/drivers/misc/genwqe/genwqe_driver.h
> > > > +++ b/drivers/misc/genwqe/genwqe_driver.h
> > > > @@ -36,7 +36,7 @@
> > > >  #include <asm/byteorder.h>
> > > >  #include <linux/genwqe/genwqe_card.h>
> > > >  
> > > > -#define DRV_VERS_STRING		"2.0.15"
> > > > +#define DRV_VERS_STRING		"2.0.21"
> > > 
> > > Why is this even needed?  Can't you go off of the kernel version number
> > > now?  Who needs / wants this number?
> > 
> > I am aware that if just considering the mainline kernels, we could use
> > the kernel version itself for the purpose of identifying which code we
> > are running.
> 
> Which is what you are patching here :)
> 
> > But in our lab we are running multiple back-ported versions of this
> > driver on different Linux distributions using different kernel versions.
> 
> Then deal with that in the backported code, the upstream kernel doesn't
> care about this.
> 
> > Our user-space software needs to know if the driver has or has not
> > bug-fixes or features. For this purpose, we are using this extra number.
> 
> Why would you rely on a version number for this, shouldn't you be able
> to tell with your api what features are present?

For version "2.0.15" there is no automatic recovery for certain
problems, for "2.0.21" there is.

I personally use the driver versions sysfs entry if a user complains
that something e.g. the recovery is not working right. First thing I am
asking for is the version of the code/driver  as part of the debug data.
If that is not matching my expectations, I will tell the user to update
the code.

In the current example new applications could more gracefully handle
failing recovery scenarios by knowing that the old version of the code
cannot properly handle certain problems. And it could this without
knowing if it is using a driver which is in the mainline tree or if it
is a back-ported version.

Therefore I find it much more convenient for us to handle such things
and I would kindly ask you to accept patch 4/4.

> thanks,
> 
> greg k-h

Thanks

Frank

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/