[Nut-upsdev] Spurious messages on start

[Arjen de Korte]

>> I committed this change to the trunk. Do you think we should change the
>> behaviour of the DUMPALL command in the drivers, to make sure ups.status
>> is the first that is sent? Otherwise (in case of newhidups for instance)
>> we might be dumping lots of (irrelevant) data before ups.status is
>> finally
>> updated. Or would it be better to just ask for ups.status first and then
>> perform a DUMPALL, so that the order in which the data arrives is no
>> longer relevant? The first could be accomplished rather easily by
>> putting
>> ups.status in the root of the tree and changing the order how the tree
>> is
>> being walked through. Which by the way is a nice side effect of setting
>> ups.status to "WAIT" after clearing the tree in the server, it will
>> always
>> be in the root.
> Probably, from the point of view of robustness, a server-side solution
> is better than driver-side. Changing all the drivers will be no fun
> task, and is prone to error. Some drivers may implement a fixed
> communication sequence to obtain their ups.status information, and in
> some cases (like newhidups), the status flags are actually assembled
> from a variety of device-side variables.

That's not quite what I meant. I want to change the order in which the
DUMPALL command spits out the dtree_info data. As I already wrote in my
reply to Arnaud, currently this is in alphabetical order by variable name.
Not quite what we would like, since the most interesting one (ups.status)
will probably not be among the first ones we get.

We might however change the order (not the contents) such, that the
st_tree_dump_conn() will (almost) start with "ups.status". This will have
little to no impact to the driver, since this is in dstate.c (common for
all drivers). With a little moving around some statement and putting a
placeholder "ups.status" in the dtree_root before we start populating the
other values, we can make sure that the DUMPALL command will start with
"ups.status". Since upsd (and therefor, upsmon too) no longer depends on
the completion of the DUMPALL, this effectively means that we are able to
monitor the status a lot sooner. See also how much faster upsd starts up
now, now it no longer has to wait for the DUMPALL command to complete.

Best regards, Arjen