netdev - Re: [PATCH v2 net-next] net: stmmac: add drop transmit status feature

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:   Wed, 12 Apr 2017 16:43:38 +0100
From:   Joao Pinto <Joao.Pinto@...opsys.com>
To:     David Miller <davem@...emloft.net>, <Joao.Pinto@...opsys.com>
CC:     <andrew@...n.ch>, <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 net-next] net: stmmac: add drop transmit status feature

Às 4:28 PM de 4/12/2017, David Miller escreveu:
> From: Joao Pinto <Joao.Pinto@...opsys.com>
> Date: Wed, 12 Apr 2017 16:13:33 +0100
> 
>> Às 3:51 PM de 4/12/2017, David Miller escreveu:
>>> You cannot develop performance based features and only test their
>>> impact on FPGA when almost all users are on real silicon.
>>>
>>> And this requirement is absolutely non-negotiable.
>>>
>>> You must test the impact on real silicon otherwise your performance
>>> numbers, which are required to be provided in the commit message
>>> for any "performance" feature or change, are completely useless.
>>
>> Next time I won't mention anything about performance, honestly. "Drop TX Status"
>> is just an IP Core feature that can or not be used, it is up to the driver user.
> 
> Being dishonest about why a change might be desirable doesn't help things, in fact
> now that you've stated this intent in the future, people know to be suspucious of
> your changes.

Dishonest? I just sent the patch adding a optional configuration that can boost
performance in applications where timestapping is not an issue. You can request
more info in stmmac.txt, but calling me dishonest is a bit out of line.

I perfectly accept if you feel that the patch is not useful, that's fine.

> 
> I seriously don't think you realize the ramifications of what you just said right
> there.

No, I don't see honestly. I just said that I am a developer that has an interest
in the success of stmmac, but I don't want to steal maintenance seats :).

> 
> Everything here is about trust, and if you create a situation where you can't be
> trusted then the process of doing upstream development will be extremely difficult
> and time consuming for you.

Agree, trust is fundamental. I never gave reasons not to be trusted, in fact I
have a good relation with some of the stmmac developers and in other subsystems,
so I don't see the point of your observations.

> 
> Thanks.
> 

Joao