On Fri, Mar 26, 2021 at 02:09:36PM -0700, Don Bollinger wrote:
quoted
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
quoted
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