2008/3/21, Arjen de Korte <[EMAIL PROTECTED]>: > > 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/ _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
