netdev - Re: [PATCH v2] eeprom/optoe: driver to read/write SFP/QSFP/CMIS EEPROMS

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:   Mon, 15 Mar 2021 10:39:50 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     "Don Bollinger" <don@...bollingers.org>
Cc:     "'Andrew Lunn'" <andrew@...n.ch>, <arndb@...db.de>,
        <gregkh@...uxfoundation.org>, <linux-kernel@...r.kernel.org>,
        <brandon_chuang@...e-core.com>, <wally_wang@...ton.com>,
        <aken_liu@...e-core.com>, <gulv@...rosoft.com>,
        <jolevequ@...rosoft.com>, <xinxliu@...rosoft.com>,
        "'netdev'" <netdev@...r.kernel.org>,
        "'Moshe Shemesh'" <moshe@...dia.com>
Subject: Re: [PATCH v2] eeprom/optoe: driver to read/write SFP/QSFP/CMIS
 EEPROMS

On Sat, 13 Mar 2021 13:35:56 -0800 Don Bollinger wrote:
> > away parts of the bottom end and replace it with a different KAPI, and
> > nobody will notice? In fact, this is probably how it was designed. Anybody  
> 
> Actually everyone who touches this code would notice, each implementation
> would have to be modified, with literally no benefit to this community.

You keep saying that kernel API is "of no benefit to this community"
yet you don't want to accept the argument that your code is of no
benefit to the upstream community.

> optoe does not undermine the netlink KAPI that Moshe is working on.  

It does, although it may be hard to grasp for a vendor who can just EoL
a product at will once nobody is paying for it. We aim to provide
uniform support for all networking devices and an infinite backward
compatibility guarantee.

People will try to use optoe-based tools on the upstream drivers and
they won't work. Realistically we will need to support both APIs.

> If your community is interested, it could adopt optoe, WITH your
> KAPI, to consolidate and improve module EEPROM access for mainstream
> netdev consumers.  I am eager to collaborate on the fairly simple
> integration.

Nacked-by: Jakub Kicinski <kuba@...nel.org>

Please move on.