Hi,
Le Fri, 14 Oct 2016 19:09:31 +0200
Albert ARIBAUD a écrit:
> How exactly is that second is totally related to how dnsmasq
> handles time?
Ahem. Rolling that back.
How is that second issue related to now dnsmasq handles time?
With apologies.
Amicalement,
--
Albert.
Hi,
Le Fri, 14 Oct 2016 19:46:13 +0500
"Vladislav Grishenko" a écrit:
> > 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).
>
> It does (actually not due sleeping,
Hi Albert,
> The clock and the RTC are two different things.
Of course they are.
In my opinion, RTC in dnsmasq terms shouldn't be literally treated as it
exactly is, but as main (original) reason leads to local time available to
application is not equal to real time.
If platform has no RTC chip,
Hi Vladislav,
Le Fri, 14 Oct 2016 11:52:33 +0500
"Vladislav Grishenko" 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 th
On 10/14/2016 02:52 AM, Vladislav Grishenko wrote:
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
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?
> 2. The man mage for ti
