[Nut-upsdev] News about libusb-1.0(+0.1) support effort

[Jim Klimov]

Hello world,

  As posted at
https://github.com/networkupstools/nut/issues/300#issuecomment-969385505
and https://github.com/networkupstools/nut/issues/300#issuecomment-970243340
in greater detail, during the past weekend I have updated the "libusb-1.0"
and "libusb-1.0+0.1" branches in NUT repository, so their proposed changes
are integrated over the past few years of development in the master branch,
and benefit from diverse building scenarios and environments on the new NUT
CI farm.

  On one hand, this allows for more relevant testing for end-users (without
having to choose *either* trying recent master-branch updates to NUT
drivers, *or* trying if newer libusb-1.0.x (with one of the implementations
of NUT logic for using it) resolves connectivity and other issues.

  Of course, over time these branches and master would differ again (so I
hope to merge one of them after community testing and review), but layering
newer master changes on top of their current state should be easier for
people who would build such mixed-not-stirred NUT codebase experimentally
in the future.

  On another hand, for developers and maintainers this branch resync allows
to revise how the two branches differ between themselves and from master.
It seems that "libusb-1.0+0.1" started from some point of "libusb-1.0", but
I am not instantly sure if it is a superset, or if "libusb-1.0" also
evolved after that bifurcation (other than `configure` script support added
by me in the past few days) -- and there are some change sets from both
that need to get into NUT. It should be much easier than before to find
out, and I hope to get to that part during some next weekends.

  What this merging effort did uncover however, is that the code (both
"original" master and in those branches) is plagued with some magical
numbers that probably mean macros (specific? bit-masks?) defined in libusb,
and at that with different names for different versions. And it may be an
issue for recently merged efforts to make USB "endpoint" and "interface"
numbers configurable and not hardcoded.

  This is detailed with examples in the issue linked above, so the goal of
this message is: if you, dear reader, know your way around the logic and
data of libusb (0.1, 1.0 or both), please take some time to figure out what
happens with those calls in libusb(0,1).c and very similarly in some driver
sources, to post PRs that would comment the logic behind numbers that
should remain, or replace with proper macros and bit/math operations for
those that should not be hardcoded and magical.

Thanks in advance,
Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20211116/3280e726/attachment.htm>