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

[Arnaud Quette]

2008/3/21, Arjen de Korte <nut+devel at de-korte.org>:
> > btw, I'm finalizing the very last changes for 2.2.2-pre1 (--with-lib
>  > becoming --with-dev + NEWS and UPGRADING completion).

ok, this has been done.
proof reading of NEWS and UPGRADING are welcome.

>  > 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.

yep, sorry for this.
I'm currently facing a flood of unplanned meeting that suck most of my
work time. I've planned some testing tomorrow since I'm done with my
dev tasks for 2.2.2... still between 2 meetings.

> 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.

I've added a note in UPGRADING. For the rest, do the necessary
changes, and we (you, Charles and me) we'll do some testing. I also
intend to call the other USB involved guys for a testing round once
-pre1 is around.

About testing, Kjell is working on a compat script for new model submission.
This should also help us in giving some testing guidance to our users.
I hope this will help us in avoiding the present situation and
attracting more people in the testing room.

>  - 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).

agree with all the above.

Do you still hold some changes?
thanks,
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/