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: in drivers/bcmxcp_usb.c::get_answer function, usb_interrupt_read 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. The other usages may be easily replaced by both POSIX clock or time_t, IMO. Regards, vasek ----------------------------- Eaton Elektrotechnika s.r.o. ~ S�dlo spolecnosti, jak je zaps�no v rejstr�ku: Kom�rovsk� 2406, Praha 9 - Horn� Pocernice, 193 00, Cesk� Republika ~ Jm�no, m�sto, kde byla spolecnost zaregistrov�na: Praha ~ Identifikacn� c�slo (ICO): 498 11 894 ----------------------------- _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
