[Nut-upsdev] GPIO as NUT driver interface?

[Jim Klimov]

FWIW, there is precedent with libusb{1,0}, libshut and libhid which
abstract NUT operations from a "backend lib" to build against; similar for
serial.c used by many drivers. Take care to not conflict by filenames with
"real" third-party libs used by the build - especially to avoid mixups for
headers and in docs/discussion.

Jim

On Thu, Feb 23, 2023, 22:16 MODRIS BĒRZONIS <modrisb at apollo.lv> wrote:

> 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.
>
>
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230224/fe85df70/attachment.htm>