netdev - RE: [EXT] Re: [PATCH net-next 14/14] qed: 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <MN2PR18MB31829FA8377460DDB9675596A10F0@MN2PR18MB3182.namprd18.prod.outlook.com>
Date:   Thu, 23 Jan 2020 08:18:08 +0000
From:   Michal Kalderon <mkalderon@...vell.com>
To:     Leon Romanovsky <leon@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>
CC:     Ariel Elior <aelior@...vell.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>
Subject: RE: [EXT] Re: [PATCH net-next 14/14] qed: bump driver version

> From: linux-rdma-owner@...r.kernel.org <linux-rdma-
> owner@...r.kernel.org> On Behalf Of Leon Romanovsky
> Sent: Wednesday, January 22, 2020 8:21 PM
> To: Michal Kalderon <mkalderon@...vell.com>
> Cc: Ariel Elior <aelior@...vell.com>; davem@...emloft.net;
> netdev@...r.kernel.org; linux-rdma@...r.kernel.org; linux-
> scsi@...r.kernel.org
> Subject: Re: [EXT] Re: [PATCH net-next 14/14] qed: bump driver version
> 
> On Wed, Jan 22, 2020 at 04:39:26PM +0000, Michal Kalderon wrote:
> > > From: Leon Romanovsky <leon@...nel.org>
> > > Sent: Wednesday, January 22, 2020 6:14 PM
> > >
> > > --------------------------------------------------------------------
> > > -- On Wed, Jan 22, 2020 at 05:26:27PM +0200, Michal Kalderon wrote:
> > > > The FW brings along a large set of fixes and features which will
> > > > be added at a later phase. This is an adaquete point to bump the
> > > > driver
> > > version.
> > > >
> > > > Signed-off-by: Ariel Elior <ariel.elior@...vell.com>
> > > > Signed-off-by: Michal Kalderon <michal.kalderon@...vell.com>
> > > > ---
> > > >  drivers/net/ethernet/qlogic/qed/qed.h | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > >
> > > We discussed this a lot, those driver version bumps are stupid and
> > > have nothing close to the reality. Distro kernels are based on some
> > > kernel version with extra patches on top, in RedHat world this "extra"
> > > is a lot. For them your driver version say nothing. For users who
> > > run vanilla kernel, those versions are not relevant too, because
> > > running such kernels requires knowledge and understanding.
> > >
> > > You definitely should stop this enterprise cargo cult of "releasing
> software"
> > > by updating versions in non-controlled by you distribution chain.
> > >
> > > Thanks
> > Due to past discussions on this topic, qedr driver version was not added
> and not bumped.
> > However, customers are used to seeing a driver version for qed/qede We
> > only bump major version changes (37 -> 42)  and not the minor versions
> anymore.
> > This does give a high-level understanding of the driver supports, helps us
> and the customers.
> 
> It is worth to talk with customers instead of adding useless work for
> everyone involved here.
Hi Leon, 

I understand your arguments, and for new drivers I agree it is best to start without a driver version, having said that
Customers are used to what is already out there. 

Ethtool displays a driver version, and  customers go by driver version, not kernel version. 
Mlx drivers haven't bumped the driver version, but it is still displayed when running ethtool. 

Having this version in upstream driver also helps us to understand the level of changes in the inbox driver.
As you mentioned, in some distributions like RHEL, kernel version has no meaning as they backport much newer functionality from upstream.
It is difficult to know based on RedHat kernel/driver, how the driver compares with the upstream driver or what functionality is there.
We have seen that the driver version greatly helps customers here.

Of course if a decision is taken to remove all ethernet driver versions from all vendors and remove the version display from ethtool
We won't object, but since it is still there, and the driver version until now does correlate in the high-level sense to functionality,
I don't see the harm in this single patch.

Dave, what is your take on this ? 
Thanks,
Michal

> 
> Thanks
> 
> >