[Nut-upsdev] NUT Bugs #313634 & #313714: unification & encapsulation of timer proposition

[Arnaud Quette]

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 <VaclavKrpec at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20121009/0b395004/attachment.html>