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 <k...@kernel.org> > > Please move on. My community still has useful code that they would like in the upstream kernel. Don
