netdev - Re: [PATCH net-next] drivers/net: add 6WIND SHULTI support

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: <20160428.115419.1831238411921569629.davem@davemloft.net>
Date:	Thu, 28 Apr 2016 11:54:19 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	nicolas.dichtel@...nd.com
Cc:	jiri@...nulli.us, fw@...len.de, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] drivers/net: add 6WIND SHULTI support

From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
Date: Thu, 28 Apr 2016 13:59:34 +0200

> Le 27/04/2016 18:55, David Miller a écrit :
>> From: Jiri Pirko <jiri@...nulli.us>
> [snip]
>>> The difference is that it this tries to allow userspace crap to mirror
>>> setting user does for bridge/ovs. Basically this looks to me like an
>>> attempt to enable userspace SDKs and such.
>> 
>> +1
> I don't think so because a userspace can receive all the bridge/ovs settings by
> mean of netlink mirror, without the need for this driver at all.

You can say whatever you want, but the facilities you are adding to
this driver enables proprietary userland SDK components.

And this is precisely what we are trying to avoid by having a clean,
fully featured switch device model in the kernel.

It is against your interestes of upstreaming your driver to continue
denying what your changes facilitate.

THanks.