hwclock recent commits - question

hwclock recent commits - question

[Michal Soltys]

Namely regarding commit:

839be2ba6b44fa9dc927f081d547ebadec9de19c

and subsequent Tom's fix:

910a090039cbd529041bfb5f6be72bf27a96bd47


 From what I can see, the "old" and current hwclock's behaviour is 
actually identical, with exception of relying on either warp_clock() 
call (current version, one-shot only) or do_settimeofday() (previous 
version, consistent on each call).

Was the switch to warp_clock() the main reason after the change, or were 
there other issues with standard approach ?

Re: hwclock recent commits - question

[Karel Zak]

On Wed, Dec 19, 2012 at 04:50:42PM +0100, Michal Soltys wrote:
> Namely regarding commit:
> 
> 839be2ba6b44fa9dc927f081d547ebadec9de19c
> 
> and subsequent Tom's fix:
> 
> 910a090039cbd529041bfb5f6be72bf27a96bd47
> 
> 
> From what I can see, the "old" and current hwclock's behaviour is actually
> identical, with exception of relying on either warp_clock() call (current
> version, one-shot only) or do_settimeofday() (previous version, consistent
> on each call).
> 
> Was the switch to warp_clock() the main reason after the change, or were
> there other issues with standard approach ?

 Yes, we want to use the warp_clock(), the problem with the old
 version is that without warp_clock() the time will be modified every
 time. It's unexpected, because the time should be modified only once
 (=during boot).
 
 Unfortunately we have bug reports from "creative people" who are able
 to call hwclock --systz more then once. The current warp_clock()
 based solution is more robust.

 Note that systemd uses the same method to setup system time (it does
 not call hwclock).

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com