[Nut-upsdev] Implementation of custom USV solution driver from manufacturer

[Charles Lepple]

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>