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
