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

Arnaud Quette aquette.dev at gmail.com
Tue Oct 9 11:40:47 UTC 2012


Hi Vasek

2012/10/8 <VaclavKrpec at 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:clepple at gmail.com]
> > Sent: Monday, October 08, 2012 2:36 PM
> > To: Krpec, Vaclav
> > Cc: Arnaud Quette; Emilien KIA; nut-upsdev at 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 at gmail
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20121009/ed8320fa/attachment-0001.html>


More information about the Nut-upsdev mailing list