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 10:51:01 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     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

From: Joao Pinto <Joao.Pinto@...opsys.com>
Date: Wed, 12 Apr 2017 14:55:03 +0100

> Understand your point, but for now our development and testing setup will be
> based on the IP Prototyping Kit, consisting of a FPGA + PHY.

That's completely, and utterly, unacceptable.

I will be quite frank with you, that instances like this are causing
people to contact me privately and telling me that your handling of
becomming the stmmac driver maintainer is causing very real and
serious concerns.

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.

I want your attitude on these matters to change quickly, as myself
and many other interested parties are becomming extremely frustrated
with how you are handling things.

Thank you.