Hi Vasek 2012/10/8 <vaclavkr...@eaton.com>
> Hello Charles, > > you can take a look at the code in branches/Vaclav/common/clock.c vi > viewvc. > > Clarification: I do clock_gettime(CLOCK_MONOTONIC, &tm) and if that > fails with EINVAL and the user requested MONOTONIC_PREF (i.e. fall-back > to RTC is allowed), I do another clock_gettime(CLOCK_REALTIME, &tm) > which should always work. > > However, I wonder whether this isn't too cautions; accordingly to the man, > as long as _POSIX_MONOTONIC_CLOCK macro is defined, CLOCK_MONOTONIC > is available. > On the other hand, build on HPUX prooved that this may not be true; > HPUX 11 defines _POSIX_MONOTONIC_CLOCK, but apparently doesn't define > CLOCK_MONOTONIC. > I mean, if this is possible, then it might also be possible that > CLOCK_MONOTONIC > is defined, but the call fails... The question is how pedantic/ paranoid > should I be? > The below link will provide you a good summary of the situation, what we can do and how. AFAICT, there is no way on HPUX (and some other older Unix) to use clock_gettime with CLOCK_MONOTONIC, but CLOCK_REALTIME (which is functionally different). gethrtime (high resolution time) seems to be the fallback here: http://nadeausoftware.com/articles/2012/04/c_c_tip_how_measure_elapsed_real_time_benchmarking but this requires (for HPUX) the native compiler and CFLAGS set to "Extended Ansi" mode... so there is a 2nd (more general) fallback, using... gettimeofday! :-/ Another reading on configure checks: http://www.nco.ncep.noaa.gov/pmb/codes/nwprod/gempak/nawips2/extlibs/glib/v2.15.6/configure.in As a separate comment, here is the list of remaining gettimeofday: common/common.c: gettimeofday(&now, NULL); drivers/bcmxcp_usb.c: gettimeofday(&start_time, NULL); drivers/bcmxcp_usb.c: gettimeofday(&now, NULL); drivers/dstate.c: gettimeofday(&now, NULL); drivers/main.c: gettimeofday(&timeout, NULL); drivers/usbhid-ups.c: gettimeofday(&now, NULL); cheers, Arnaud > -----Original Message----- > > From: Charles Lepple [mailto:clep...@gmail.com] > > Sent: Monday, October 08, 2012 2:36 PM > > To: Krpec, Vaclav > > Cc: Arnaud Quette; Emilien KIA; nut-upsdev@lists.alioth.debian.org List > > Subject: Re: [Nut-upsdev] NUT Bugs #313634 & #313714: unification & > > encapsulation of timer proposition > > > > [adding nut-upsdev back to CC list.] > > > > > While you at it --- I've written the nut_clock_gettime POSIX > > > implementation so that fallback from monotonic POSIX clock impl. to > > > RTC is actually also done if the system defines _POSIX_MONOTONIC_CLOCK > > > macro, but the call ends with EINVAL (i.e. not implemented) if > monotonic clock > > is requested. > > > I thought that may be a bit over-protective; as soon as the OS defines > > > the detection macro, we should be entitled to expect it to work; > > > EINVAL should therefore be considered an error and propagated. > > > > I'm confused. Could you post pseudocode, or the actual patch, for what > is being > > described above? > > > > -- > > Charles Lepple > > clepple@gmail > > > > > >
_______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev