Nut upsdev - Mar 2008 - [nut-commits] svn commit r1376 - in trunk: . server

Hi Arjen,

there is a small glitch with r1376:
upsd.c: In function ?mainloop":
upsd.c:857: warning: too few argument for the format


2008/3/18, Arjen de Korte <adkorte-guest at
alioth.debian.org>:
> Author: adkorte-guest
>  Date: Tue Mar 18 19:59:15 2008
>  New Revision: 1376
> ...
>  +       if (ret == 0) {
>  +               upsdebugx(2, "%s: no data available");
                                             ^^^

I let you fix it since I don't know what you want to print out or if
you've simply omitted the "%s"

btw, I'm finalizing the very last changes for 2.2.2-pre1 (--with-lib
becoming --with-dev + NEWS and UPGRADING completion). Do you hold some
more on netxml and Bruce related subjects?

Arnaud
-- 
Linux / Unix Expert R&D - MGE Office Protection Systems -
http://www.mgeops.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/

> btw, I'm finalizing the very last changes for 2.2.2-pre1 (--with-lib
> becoming --with-dev + NEWS and UPGRADING completion). Do you hold some
> more on netxml and Bruce related subjects?
Yes, there are:

- drivers/usbhid-ups:
I intend to backport all the changes that are still in the trunk. Despite
having asked for comments and testing numerous times on the Development
mailing list over the past few weeks (and months), I have received little
to no comments. So either these changes are the best thing since sliced
bread, or I am the only active developer with a USB HID UPS. Either way, I
see no alternative other than by backporting this to Testing get feedback
from the field (and see what happens). The version we have now in Testing
broke some devices with exceptionally long report descriptors, so we'll
have to do something here anyhow.

- clients/upsclient.c:
I'm working on resolving a bug here, where the clients block if the server
is not responding. The solution is to use select() to allow the server
some time (5 seconds, in order not to wait to long) to send an answer and
if this doesn't arrive, give up on it and disconnect. To make things more
robust the other way around, we'll use a similar mechanism for sending
data to the server.

- drivers/dstate.c:
Basically the same is true here. We don't handle situations like the above
gracefully when sending something to the server. On a highly loaded server
when the IPC pipe is getting full, the write() command that sends data to
the server fails eventually. Again, a select() on sending data to the
server with a timeout value of 5 seconds might solve that (by preventing
the the driver from sending more data when the pipe is already full).

The recent changes to the server will *not* go into Testing. I'm not
entirely sure that this is portable on older platforms. Since the audience
for servers handling more than FD_SETSIZE connections will be quite
limited, I don't think we have a lot to gain by hurrying this to Testing
(although the poll() mechanism is a somewhat cleaner solution than
select() is).

Best regards, Arjen