[Nut-upsdev] Merging libeaton (was Re: [nut-commits] buildbot failure in Network UPS Tools on Fedora-x64)

Tue Nov 29 14:50:39 UTC 2011

2011/11/28 Charles Lepple <clepple at gmail.com>:
> On Nov 26, 2011, at 11:29 AM, Arnaud Quette wrote:
>
>> 2011/11/25 Charles Lepple <clepple at gmail.com>:
>>> On Nov 25, 2011, at 9:59 AM, Arnaud Quette <aquette.dev at gmail.com> wrote:
>>>
>>>> Any comment from your side on a possible integration in the trunk?
>>>> I'm too biased to consider my voice relevant here...
>>>
>>> You think I'm unbiased? :-)
>>
>> probably more than me on this point, at least for the public ;-)
>> but I'm conscious that this merge would be part of the gesture of
>> appreciation toward Eaton...
>
> I guess it would be a gesture of appreciation towards Eaton, but as you mention below, people are primarily directing their requests for this sort of library to Eaton, not towards the NUT project. You are essentially asking for the rest of the project to bear the maintenance burden for some alpha code that doesn't really benefit the project much.

well, not exactly:
- the code used is the same as the existing one,
- the special target (configure option) is not enabled by default, so
not generating overhead on our (NUT) current scope,
- publication and support would still be handled by Eaton,

> We have already seen this sort of increased maintenance burden from the Win32 binaries (which aren't quite to the point where they can easily be built by users outside of Eaton).

the point there was to fill a NUT lack. Eaton is not providing "Eaton
only" packages for Windows, but generic builds for all.
Early windows build were also a way to maximize testing and feedback.

>>> I haven't had much of a chance to look at the code,
>>
>> once you've trimmed the doc, there doesn't remain much apart from the
>> build rules.
>
> There may not be much, but now we have even more duplication of dstate-related code. I think it would be best to hold off on merging until we come up with a cleaner middle layer for this HAL/dstate/libeaton stuff.

this is still floating somewhere in my brain.
the issue being runtime Vs compile time interfaces:
libeaton is clearly compile time, while the classic dstate, and
HAL/UPower variation are more runtime (even if it's currently a
compile time approach).

>>> but by default, I am skeptical of libraries which try to abstract away all of the complexities of bidirectional communication with hardware. I may have missed this in the documentation, but what problem does this solve that isn't addressed by the rest of NUT? Is this intended for GUI apps? If so, how does this interact with event loops or threading? Have full-fledged apps been written against this API?
>>
>> none apart from the examples in the doc.
>> the aim is to provide a simple solution to a simple problem: what if
>> people just want to get ups.status (and possibly a few more) in their
>> "god" app, in order to act smartly. I've had so many requests of this
>> type, since the old MGE time, you'll never know!
>> some people only use drivers and interface with these.
>> some use the whole framework and other only a handful of data and a lib.
>> all this is simply NUT drivers available as libs (Ie, we have only
>> removed main.c!). no more, no less.
>> all NUT limitations still apply. and the user needs to reimplement NUT
>> driver main.c on his own.
>
> Maybe a diagram would explain this better? Does a user essentially compile driver code into their app, hardcoding it to a single device type (USB HID, SHUT, XML, etc.)? Or does the libeaton-based app have all drivers available? I think I know how this works from reading the code, but if my experience with libhid has taught me anything, it's that nobody looking for an easy solution will ever read library source code (no matter how much you declare it to be a simple wrapper around another library).

part of the possible improvements.
the current approach is indeed limited to compiling *1* specific lib,
that hardcode communication with a single device (USB/HID or USB/XCP
or serial XCP or serial SHUT or SNMP...).
Very limited, but the aim, as described in the others paragraphs, is
also to advocate the full NUT framework, while still satisfying the
simple but limited "lib approach".

>>> I don't personally see any urgency to merge this into the trunk, but I am willing to be persuaded otherwise.
>>
>> well, the only urgency I see is that it increase the sync overhead
>> around branches on my small Eaton team.
>> also considering that Fred will be on paternity leave soon, this waste
>> work force that could be used otherwise.
>
> Not sure I follow this reasoning. If the code is mostly independent of NUT, why can't the branch just wait until we're not rushing to get another release out the door? Especially if we're considering moving to Git for our central code repository, where rebasing the branch on top of the trunk should be fairly effortless.

you got a point, but only if we move quickly to git (and I'm all for!)

>> I'd like to get this small one done for 2.6.3, so that we can then
>> concentrate on windows + nss merges and "bindings" improvements. and
>> also in order for me to concentrate on these infrastructure and cloud
>> integrations.
>
> I think it needs some work before merging, especially considering your proposed short timeline for 2.6.3. I can't find a link to one of the "how to write a library API" guides that I think would be very applicable here, but as I alluded to earlier, this is going to be difficult to integrate with a GUI or multiple threads (and Win32 programmers love threads). This goes back to the whole global state problem.

right, known limitation.
I have something in mind around that, and upsdrv_*() functions (an
extension of the upsdrv_info structure).
But this also requires upsdrv_*() prototypes changes and global vars
hunting, before we can start to claim MT safeness.
And it was not inline with our timelines. Scheduled for a 2nd phase.

> Also, you probably want to clarify that we only work with libusb-0.1(.12), and that libusb-compat may cause problems. Plus, this is a good place to document the whole "your distro probably has a -dev splitoff" problem. The recommended version numbers for the other libraries (or at least the versions you tested) would probably be useful to have in the documentation as well.

for the time being, the focus is on the binary delivery (the
simple/easy way), and not on the compilation side.
We've tracked down your relevant comments, and will update the
documentation accordingly.

thanks and cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/