<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Name is now generic_gpio_libgpiod, sort
of long...</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Modris</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 2/24/23 01:00, Jim Klimov wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJYg8vKntNq6NrhJe-1Ugmk929ufEBr+mi1E+Wvs4BbcBtaw_A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">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.
<div dir="auto"><br>
</div>
<div dir="auto">Jim</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Feb 23, 2023, 22:16
MODRIS BĒRZONIS <<a href="mailto:modrisb@apollo.lv"
moz-do-not-send="true" class="moz-txt-link-freetext">modrisb@apollo.lv</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Did
refactoring to better split library specifics, now see <br>
open/close/read lines that any library should support. Need to
split <br>
into 2 files, may to go for library?<br>
<br>
On 2/22/23 20:17, Greg Troxel wrote:<br>
> Jim Klimov via Nut-upsdev <<a
href="mailto:nut-upsdev@alioth-lists.debian.net"
target="_blank" rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">nut-upsdev@alioth-lists.debian.net</a>>
writes:<br>
><br>
>> Nearby there's also a `generic_modbus" name.
Wondering if the new driver<br>
>> should be (similar to) `generic_gpio`.<br>
> sound good.<br>
><br>
> It would be nice if there were an abstraction layer for
various GPIO<br>
> access methods, rather than hard-coding linux, even if
there is only one<br>
> implementation of the abstraction. I'm not that clear on
GPIO, but I<br>
> gather there are differences. Or maybe there is already
a portable GPIO<br>
> abstraction library?<br>
><br>
>> @Community verdict: Then there was also an effort
some years ago to name<br>
>> drivers with a `nutdrv-*` prefix... WDYT?<br>
> I see nutdrv- when used as a driver name to be
conent-free.<br>
<br>
<br>
<br>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net"
target="_blank" rel="noreferrer" moz-do-not-send="true"
class="moz-txt-link-freetext">Nut-upsdev@alioth-lists.debian.net</a><br>
<a
href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>