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: <20210315103950.65fedf2c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ