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]

Date:   Fri, 26 May 2017 12:55:22 -0400
From:   Dennis Dalessandro <dennis.dalessandro@...el.com>
To:     Saeed Mahameed <saeedm@....mellanox.co.il>
Cc:     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 5/26/2017 12:35 PM, Saeed Mahameed wrote:
> On Fri, May 26, 2017 at 3:56 PM, Dennis Dalessandro
> <dennis.dalessandro@...el.com> wrote:
>> On 5/23/2017 7:44 AM, Saeed Mahameed wrote:
>>>
>>> From: Tariq Toukan <tariqt@...lanox.com>
>>>
>>> Remove date and bump version for mlx5_core driver.
>>>
>>> Signed-off-by: Tariq Toukan <tariqt@...lanox.com>
>>> Signed-off-by: Saeed Mahameed <saeedm@...lanox.com>
>>
>>
>> So I just complained about the bnxt_re doing this. I guess I need to raise a
>> flag here too. Now to be clear I'm not against doing this version stuff. I'm
>> against using it for some internal tracking that is meaningless to the
>> kernel community.
>>
>> There is no detail in your commit message as to what this driver version is
>> used for. Can you please explain how your use of driver version is valid
>> while theirs is not?
>>
> 
> Hi Denny,
> 
> We don't use this for internal or any kind of tracking at all, if you
> look at the driver change log, we hardly touch the version if at all !
> 
> but since we decided to remove the date since it is very misleading
> and we got some complaints that some think they have an old driver
> just because of the date, also we bumped the version so it would align
> with our drivers external package (OFED).

To me that's not a reason to include something in the kernel. At least 
your external package is something that is available and not an internal 
development process, but still probably no interest to anyone in the kernel.

> Anyway i don't think we are going to change this frequently or even use it.

> But if you are that much against touching this ethtool field, why
> don't you just jump into the mud and remove it from the tree, I
> imagine it is really hard for you to watch for patches doing this and
> nack them on the list.

I have no interest in policing that. I complained about the other driver 
because I know patches like that were NAKed by Greg KH in the past 
(ours). I'd rather not see the rdma subsystem keep making the same 
mistakes is all. We want to improve our standing in the community after 
all. As I said I'm not personally against it as evidenced by our driver.

>> 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.

-Denny