The code you are talking about is very old, from before I started
hacking the usbhid-ups driver. It is definitely in need of an
overhaul.
The hid_info_t structure has evolved over time. From what I
understand, initially, NUT variables could be only constant strings or
directly mapped UPS variables. A multiplier was probably added later
to allow for a change of units (e.g. Volts instead of 0.1 Volts). Yet
later, lookup tables were added to allow for symbolic values such as
"on", "off" etc. Yet later, I generalized the lookup tables
to
arbitrary conversion functions, which are however tied into the lookup
table mechanism via a special rule. Meanwhile, the multiplier must
have become obsolete at some point, either when proper parsing of HID
units was implemented, or when the generalized conversions were
introduced. There is also a "format" field which is mostly, but not
always, ignored.
All this needs to be replaced by a re-designed, cleaned-up data
structure. It's on my to-do list, but nothing on that list will get
done by me anytime soon. As nothing is technically broken, and the
changes are prone to introducing subtle bugs, this is not high on my
list anyway at the moment.
-- Peter
Arjen de Korte wrote:>
> I don't understand how the info_len element from the hid_info_t
structure
> is used in usbhid-ups. It appears to me that the only use of this element
> is now to indicate the length of the string:
>
> > float info_len; /* if ST_FLAG_STRING: length of the string */
>
> The above is clear, if the element is flagged as a string, the size of
> this string is put in this variable, so that we can use this in
> dstate_setaux(). But strangely enough, we use a 'float' here and
not an
> 'int'. Why? Do we expect *very* long strings?
>
> > /* if HU_TYPE_CMD: command value ; multiplier otherwise */
>
> This comment puzzles me. It looks to me that this deals with the dfl
> element (and this is just misplaced), since the this is where this flag
> ends up when used by the subdrivers, so probably this comment should be on
> a different line. But what does this 'multiplier otherwise' mean?
>
> Best regards, Arjen
> --
> Eindhoven - The Netherlands
> Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57
>
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>