Message-ID: <001201d719c6$6ac826c0$40587440$@thebollingers.org>
Date:   Mon, 15 Mar 2021 11:09:59 -0700
From:   "Don Bollinger" <don@...bollingers.org>
To:     "'Jakub Kicinski'" <kuba@...nel.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>, <don@...bollingers.org>
Subject: RE: [PATCH v2] eeprom/optoe: driver to read/write SFP/QSFP/CMIS EEPROMS

On Mon, 15 Mar 2021 10:40 -0800 Jakub Kicinski wrote:
> 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.

I have offered, in every response, to collaborate with the simple
integration to use optoe as the default upstream driver to access the module
EEPROMs.  optoe would be superior to the existing default routines in sfp.c
and would allow multiple existing vendor specific upstream drivers to adopt
the default.  That would reduce the code base they maintain and provide
better access to module eeproms.  I already adopted the existing EEPROM api
to make that integration easy (nvmem).  I'm reluctant to submit the changes
to sfp.c because I have no expertise in that stack and no platform to test
it on.

> 
> > 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.

I aim to provide uniform support for module EEPROM devices, with no less
reason to expect an infinite backward compatibility guarantee.  (Infinite is
a bit much, that technology will inevitably become uninteresting to my
community as well as yours.)

> 
> 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.

I assume they "won't work" because of new requirements or newly discovered
defects.  At that point optoe would be fixed by people who care, just like
any other upstream code.  If your stack adopts optoe, through Moshe's KAPI,
then both communities benefit from ongoing support to maintain and enhance
EEPROM access.  If your stack does not adopt optoe, then my community will
manage the support, since they need and use the code.

As for "both APIs", the first API is Moshe's, which we both support
(politically and technically).  The second is nvmem, which is supported by
the EEPROM driver folks, led by the support for the at24 driver.  I'm
calling the routines they created for this purpose, I'm not creating a new
API.

Bottom line:  "Realistically we will need to support both APIs" even if
optoe does not get accepted.

> 
> > 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.

My community still has useful code that they would like in the upstream
kernel.

Don

Powered by blists - more mailing lists