On 03/25/2013 04:08 PM, John Stultz wrote:
>
> The problem of course, is that the new asynchronous behavior the
> shadow updates breaks some of the assumptions on how the NTP state
> is used. Thus to correct this, we really need to serialize the ntp
> state updates along with the timekeeping
On 03/25/2013 04:08 PM, John Stultz wrote:
The problem of course, is that the new asynchronous behavior the
shadow updates breaks some of the assumptions on how the NTP state
is used. Thus to correct this, we really need to serialize the ntp
state updates along with the timekeeping state.
On Mon, Mar 25, 2013 at 01:08:10PM -0700, John Stultz wrote:
> This patchset makes the lock ownership lines less obvious, but I've
> been sure to keep the ntp state static to ntp.c and instead provided
> some accessors via ntp-internal.h that timekeping code can use to
> make changes. The only
On Mon, Mar 25, 2013 at 01:08:10PM -0700, John Stultz wrote:
This patchset makes the lock ownership lines less obvious, but I've
been sure to keep the ntp state static to ntp.c and instead provided
some accessors via ntp-internal.h that timekeping code can use to
make changes. The only
So this is sort of a frustrating patchset, as previously much work
had been done to split the NTP state out from being protected by the
xtime_lock of yore. But apparently the crystal ball was foggy back
then.
For some time now, Thomas and Eric have been pushing to use
shadow-updates on the
So this is sort of a frustrating patchset, as previously much work
had been done to split the NTP state out from being protected by the
xtime_lock of yore. But apparently the crystal ball was foggy back
then.
For some time now, Thomas and Eric have been pushing to use
shadow-updates on the
6 matches
Mail list logo