Nut upsdev - Sep 2019 - Implementation of custom USV solution driver from manufacturer

Dear Nut-Devs,

I have general question to the contribution and the handling of new code in the
NUT-Project.

We would like to implement our USV-Solution as a driver to NUT, but we are
having the problem, that
we need a powerful “C”-based gpio library for it.

We discussed this topic internally, and we are having  the opinion, that it does
make sense, to write this library separate from
a NUT-driver, and publish this gpio-library with GPLv2 to the community on our
own github repo. In the driver itself, we would like to use
this library like an API.

In the NUT-project, we want to implement the the christ-usv driver and customize
the autotools project for a dynamic compile of our driver.
The gpio-library would be a specific dependency of the christ-usv-driver and
should not affect the other drivers or the whole project itself.

We would to contribute our driver back to the official project/community and
don’t want to fork it.

Are there any reserves for new open source library dependencies in the autotools
project?
Are there any reserves in general with a view of our planed process?
Does this process fit to your normal code contribution guidelines?
Do you see any better options for a code contribution?


Thank you for your patience
Best Regards

Steffen Kothe


Christ Electronic Systems GmbH
http://www.christ-es.com/

Geschäftsführer: Franz Reichle
Hauptsitz: Alpenstraße 34, 87700 Memmingen
Amtsgericht Memmingen HRB 9102

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten
haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht
gestattet.
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please notify
the sender immediately and destroy this e-mail. Any unauthorised copying,
disclosure or distribution of the material in this e-mail is strictly forbidden.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20190924/dc949a3c/attachment.html>

On Sep 24, 2019, at 1:40 AM, Kothe, Steffen wrote:
> 
> Dear Nut-Devs,
>  
> I have general question to the contribution and the handling of new code in
the NUT-Project.
>  
> We would like to implement our USV-Solution as a driver to NUT, but we are
having the problem, that
> we need a powerful “C”-based gpio library for it.
>  
> We discussed this topic internally, and we are having  the opinion, that it
does make sense, to write this library separate from
> a NUT-driver, and publish this gpio-library with GPLv2 to the community on
our own github repo. In the driver itself, we would like to use
> this library like an API. 
Definitely, NUT drivers can link to external libraries. The most common case is
libusb: https://github.com/networkupstools/nut/blob/v2.7.4/configure.ac#L256
<https://github.com/networkupstools/nut/blob/v2.7.4/configure.ac#L256> ,
then the drivers can have their own linker flags:
• https://github.com/networkupstools/nut/blob/v2.7.4/drivers/Makefile.am#L12
<https://github.com/networkupstools/nut/blob/v2.7.4/drivers/Makefile.am#L12>
• https://github.com/networkupstools/nut/blob/v2.7.4/drivers/Makefile.am#L167
<https://github.com/networkupstools/nut/blob/v2.7.4/drivers/Makefile.am#L167>
 
> In the NUT-project, we want to implement the the christ-usv driver and
customize the autotools project for a dynamic compile of our driver.
> The gpio-library would be a specific dependency of the christ-usv-driver
and should not affect the other drivers or the whole project itself.
We have not really pushed for this before, but especially with a new external
library, it might be good to have some sort of test mode for the driver. If you
make the driver conditional on finding the GPIO library, then it might make
sense to put the test code into the library. You could read a data file which
specifies the states of the GPIO pins over time, and that would help other
developers verify that the driver and library work without needing the actual
UPS hardware.
>  
> We would to contribute our driver back to the official project/community
and don’t want to fork it.
>  
> Are there any reserves for new open source library dependencies in the
autotools project?
> Are there any reserves in general with a view of our planed process?
> Does this process fit to your normal code contribution guidelines?
> Do you see any better options for a code contribution?
That sounds good overall. I would recommend having one or more of your engineers
subscribe to this list to discuss changes - it is fairly low-traffic. Most NUT
developers won't want to answer questions off-list. We are also doing some
development on GitHub, so you can fork the project there
(https://github.com/networkupstools/nut
<https://github.com/networkupstools/nut> ) and submit your driver as a
pull request. Discussion can happen on the pull request instead, if you'd
like.

Published developer documentation is here:
https://networkupstools.org/docs/developer-guide.chunked/index.html
<https://networkupstools.org/docs/developer-guide.chunked/index.html> but
I would recommend you check the source files included here to see if anything
has changed:
https://github.com/networkupstools/nut/blob/master/docs/developer-guide.txt
<https://github.com/networkupstools/nut/blob/master/docs/developer-guide.txt>

Also, since this project is effectively maintained in the developers' spare
time, we cannot commit to timelines. We have already been derailed by some
upstream USB changes (issue #300 in GitHub) so it has been a few years since the
last NUT tarball release. Fortunately, we keep the master branch in a working
state, so if you add code based on master, you can also generate a tarball for
your users before the next official release.
>  
>  
> Thank you for your patience
> Best Regards
>  
> Steffen Kothe 
> 
> 
> Christ Electronic Systems GmbH
> http://www.christ-es.com/ <http://www.christ-es.com/>
> 
> Geschäftsführer: Franz Reichle
> Hauptsitz: Alpenstraße 34, 87700 Memmingen
> Amtsgericht Memmingen HRB 9102
> 
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail ist nicht gestattet.
> This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorised copying,
disclosure or distribution of the material in this e-mail is strictly
forbidden._______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at alioth-lists.debian.net <mailto:Nut-upsdev at
alioth-lists.debian.net>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
<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/20190924/16fdb207/attachment-0001.html>