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

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Mar 26, 2021 at 02:09:36PM -0700, Don Bollinger wrote:
> > You keep missing the point. I always refer to the KAPI. The driver we can
> > rework and rework, throw away and reimplement, as much as we want.
> > The KAPI cannot be changed, it is ABI. It is pretty much frozen the day
> the
> > code is first committed.
> 
> Maybe I don't understand what you mean by KAPI.  The KAPI that optoe exposes
> is in two parts.
> 
> First, it makes the EEPROM accessible via the nvmem() interface, an existing
> KAPI that I call from optoe.  at24 implemented it, I made use of it.  This
> interface exposes EEPROM data to user space through a defined sysfs() file.
> I didn't invent this, nor am I proposing it, it already exists.

Again, a "raw" interface to a device that is just memory-mapping all of
the device information directly is no sort of a real KABI at all.

It is no different from trying to use /dev/mem/ to write a networking
driver, just because you can mmap in the device's configuration space to
userspace.

That is not a real api, it is only using the kernel as a "pass-through"
which works fine for one-off devices, and other oddities, but is not a
unified user/kernel api for a class of device types at all.

thanks,

greg k-h