Did version with library code split into separate files - not to
library. In case if needed this could be done easily as logically code
is ready for this.
Name is now generic_gpio_libgpiod, sort of long...
Modris
On 2/24/23 01:00, Jim Klimov wrote:
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
