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 <[email protected]> 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 <[email protected]> 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 > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev >
_______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
