Re: [PATCH 0/8] Move ntp state to be protected by timekeeping lock

2013-03-28 Thread Prarit Bhargava
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

Re: [PATCH 0/8] Move ntp state to be protected by timekeeping lock

2013-03-28 Thread Prarit Bhargava
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.

Re: [PATCH 0/8] Move ntp state to be protected by timekeeping lock

2013-03-26 Thread Richard Cochran
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

Re: [PATCH 0/8] Move ntp state to be protected by timekeeping lock

2013-03-26 Thread Richard Cochran
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