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