Le Fri, 14 Oct 2016 11:52:33 +0500
"Vladislav Grishenko" <themiron...@gmail.com> a écrit:
> Hi, Albert,
> > 1. HAVE_BROKEN_RTC should be used for, well, broken RTCs. Here, we
> > are not dealing with broken RTC.
> Root issue from original mail:
> > One of which acknowledges potential problem if the clock goes
> > backwards...
> As for me it's indeed broken RTC behavior, not?
The clock and the RTC are two different things.
The RTC is what keeps time in between power-offs. It has backup power
(frequently on PCs it is a CR20xx battery) and a slow autonomous clock
source (typically a 32 kHz crystal). IT is not set or read frequently
while the system is on, because it is usually slow to access.
So while it is on, the system keeps track of the time not through the
RTC but through some internal clock reference which is easier and
faster to read and set. It is this clock reference which gets read
every time a process needs to known what time is "now", and it is what
gets affected by NTP etc.
> > 2. The man mage for times() states that "a portable application
> > would be wise to avoid using [the] value [returned by times()]. To
> > measure changes in elapsed time, use clock_gettime(2) instead".
> Because start value of posix's times() return value may vary across
> kernel versions & UNIX impl., combined with possibility of value
> overflow the clock_t range. Since we don’t care neither about initial
> boot value nor about sleep/suspended time (files can't be modified
> when suspended, right?)
But timeouts can occur, TTLs can get past, etc. To treat those properly,
dnsmasq needs to know how much time has flown while it was sleeping (if
it ever does, of course).
> - the only possible issue is overflow. Since
> times() not counting CPU ticks in sleep/supspended mode, suggestion
> clock_gettime here is about using CLOCK_MONOTONIC which is almost the
> same, but with no-overflow API.
Hm... I believe that's what my proposal amounts to on systems where
CLOCK_BOOTTIME is not available.
> > - otherwise, if CLOCK_MONOTONIC is defined (it should always) and if
> > clock_gettime(CLOCK_MONOTONIC,...) succeeds at run time, use
> > that;
> Even with defined CLOCK_MONOTONIC, the real presence of this clock
> source can be retrieved from kernel in runtime only.
Indeed, hence my double test suggestion: one must test the existence
of CLOCK_MONOTONIC and only call clock_gettime(CLOCK_MONOTONIC...) if
it exists, and mone must test the return value of clock_gettime() in
case dnsmasq runs on an older kernel/glic than it was compiled and
> Yes, there're
> old running kernels with no CLOCK_MONOTONIC, clock_gettime() returns
> EINVAL. Same check is true for CLOCK_BOOTTIME.
Exact, hence my "returns success" conditional.
> Best Regards, Vladislav Grishenko
Dnsmasq-discuss mailing list