Messages in this thread | | | Date | Sat, 27 Mar 2021 13:40:34 +0100 | From | Greg KH <> | Subject | Re: [PATCH v2] eeprom/optoe: driver to read/write SFP/QSFP/CMIS EEPROMS |
| |
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
| |