linux-kernel - Re: [PATCH 4/4] misc: hpilo: Update 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20190225214455.GA6845@kroah.com>
Date:   Mon, 25 Feb 2019 22:44:55 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Jerry Hoemann <jerry.hoemann@....com>
Cc:     Matt Hsiao <matt.hsiao@....com>, linux-kernel@...r.kernel.org,
        arnd@...db.de, david.altobelli@....com, mark.rusk@....com
Subject: Re: [PATCH 4/4] misc: hpilo: Update driver version

On Mon, Feb 25, 2019 at 01:28:05AM -0700, Jerry Hoemann wrote:
> On Fri, Feb 22, 2019 at 07:49:28AM +0100, Greg KH wrote:
> > On Thu, Feb 21, 2019 at 09:11:11PM -0700, Jerry Hoemann wrote:
> > 
> > > Our primary means of supporting Linux to our customers is via our
> > > distro partners.  While we prefer to use in distro drivers, HPE does
> > > from time to time deliver driver updates via the "Service Pack for
> > > Proliants" -- The SPP. 
> > 
> > That's fine, but again, does not matter to the in-kernel driver at all.
> 
> Your point?  No one claimed that changing the version number
> of the module changes its functionality.  We're changing the driver
> version number to reflect that the driver's functionality changed.
> 
> We do this to help determine the version running on a system
> in the event we have problems.  It's a support issue.

You last touched that version number in 2016, despite there being
changes made to the driver in the _years_ since then.  So if someone
called in and said, "I have a problem with version "1.5.0", you really
have no idea what that code is.

That shows to me that the version field in the driver means nothing, so
it should be removed.

> > I understand that in your viewpoint, your driver's version means
> > something.  But in reality, it's only the kernel's version that means
> > something because your driver is just part of the overall kernel, it
> > does not stand alone.
> 
> I never claimed a driver stood alone.  jeezz.
> 
> When you say kernel "version", are you trying to say that the version
> string printed by the kernel determines the source of the drivers?
> (I ask, because I have heard other maintainers make this claim.)

Yes.

> The kernel version string only reliably determines the base kernel build.
> Modules can be unloaded and replaced by totally new versions drastically
> different from the version that existed at the time of the base kernel build.

Sure, and if you do that you are on your own, feel free to put what ever
string you want in your external module source code.

Note, you will know that this is an "external" module, the kernel does
tell you that you did this, it is not silent at all.

> The delivery of drivers updates independent of base kernel was old
> practice when I started Unix development 30 years ago.  It was not unique
> to HPE then or now.  I don't see it stopping.

The old model of detaching drivers from the operating system is not at
play here.  When you had different distribution channels, trying to have
a version number made sense to try to get a grip on what is running
where.  That's not the case with Linux, and hasn't been for the past 20+
years.

Linux is distributed as a "whole", kernel+drivers, they are directly
tied together and are one body of work.  Yes, you can have external
modules, but that is not the normal method of operation and one I could
care less about here.  All I care about is that our tree works properly.

And as such, I will continue to state that an individual driver version
number means nothing, as it is the actual version of the kernel itself
that actually means something.

For drivers that actually have active development (unlike this one), it
is very simple to see how the module version gets out of whack.  Take
one patch that goes into the main kernel tree, and have that backported
to the stable and LTS kernels, and all of a sudden your "version number"
means nothing, as the version number of the stable kernel's copy of the
driver did not change.  And you really can't bump it to a different
number from the main version, so what do you do?  Try to come up with
some other intermediate number?  That's not ok as you can't keep up with
that numbering scheme as all that really matters is the kernel version
number itself!

Anyway, as this driver is obviously not under development at all, and
the changes that have happened since 2016 never caused you to change the
number, I'm not going to take this patch, sorry.

greg k-h