Nut upsdev - Feb 2023 - GPIO as NUT driver interface?

Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes:
> Nearby there's also a `generic_modbus" name. Wondering if the new
driver
> should be (similar to) `generic_gpio`.
sound good.

It would be nice if there were an abstraction layer for various GPIO
access methods, rather than hard-coding linux, even if there is only one
implementation of the abstraction.  I'm not that clear on GPIO, but I
gather there are differences.  Or maybe there is already a portable GPIO
abstraction library?
> @Community verdict: Then there was also an effort some years ago to name
> drivers with a `nutdrv-*` prefix... WDYT?
I see nutdrv- when used as a driver name to be conent-free.

Did refactoring to better split library specifics, now see 
open/close/read lines that any library should support. Need to split 
into 2 files, may to go for library?

On 2/22/23 20:17, Greg Troxel wrote:
> Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net>
writes:
>
>> Nearby there's also a `generic_modbus" name. Wondering if the
new driver
>> should be (similar to) `generic_gpio`.
> sound good.
>
> It would be nice if there were an abstraction layer for various GPIO
> access methods, rather than hard-coding linux, even if there is only one
> implementation of the abstraction.  I'm not that clear on GPIO, but I
> gather there are differences.  Or maybe there is already a portable GPIO
> abstraction library?
>
>> @Community verdict: Then there was also an effort some years ago to
name
>> drivers with a `nutdrv-*` prefix... WDYT?
> I see nutdrv- when used as a driver name to be conent-free.