Vasek, first, please refer to my previous answer, a few hours ago (including links). I've not bothered summing up myself, since the link does pretty well. you'll find there most if not all answers to your questions.
2012/10/9 <vaclavkr...@eaton.com> > Hi Charles, > > > I don't think we should ignore an EINVAL error, and we should fall back > to > > gettimeofday() in that case. (I know gettimeofday is deprecated, but if > > CLOCK_MONOTONIC isn't quite right, then gettimeofday should work.) > > Aw, I think I might have been too fast with condemning gettimeofday, > before. > I've actually found one point at the code where we might need it > if POSIX clock isn't available: > I've (still) not looked thoroughly enough, but I dont' see a problem here. in drivers/bcmxcp_usb.c::get_answer function, usb_interrupt_read > FYI, I've planned a rewrite of this driver, and IIRC still have a patch to apply that rewrite get_answer (still using gettimeofday() though). the time here is just to allow receiving all data chunks within XCP_USB_TIMEOUT (5 seconds). usb_interrupt_read() last param (timeout) is indeed milliseconds. function's last argument appears to be required with ms precision. > If we don't have POSIX clock in this case, the time_t fallback will > decrease the timeout precision. It is questionable, however, whether > this is indeed so important (other drivers typically use hard 1s timeout > on usb_interrupt_read). > This should be discussed, I think. > other driver generally knows how much they have to receive, and 1 request is generally sufficient. XCP tells you if the current block is last, or if you have to issue further requests. thus, the timeout is global to all these requests, and decreasing each time there is a new request. on the timeout precision, XCP uses 5 (seconds), but having everything done between 4 to 6 seconds is good enough to me. The other usages may be easily replaced by both POSIX clock or time_t, IMO. > cheers, Arnaud -- Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.fr
_______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
