[Nut-upsdev] Spurious messages on start

[Arnaud Quette]

2006/11/21, Arjen de Korte <nut+devel at de-korte.org>:
>
> > I finally understand what the DUMPALL command does. I agree with your
> > proposal. It's fine for upsmon sit there and watch the variable list
> > slowly get populated, as long as ups.status is present.
>
> 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.

that seems to suit me too.
note that my prev proposition to ensure the driver has really detected
the UPS was simply to rely upon upsdrv_init*, so not calling the
initial upsdrv_update.
This allows both to speed up the process while ensuring there is
really a device out there. The other way of enforcing the initial
update with only feeding the status would also be a solution (but need
some tests).

All the above is driver side, not server side as Arjen's proposition,
and more intrusive too.

Arnaud
-- 
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/