From: Karel Zak <kzak@redhat.com>
To: JWP <elseifthen@gmx.com>
Cc: util-linux@vger.kernel.org
Subject: Re: [PATCH 6/7] hwclock: Add --update option
Date: Tue, 14 Oct 2014 11:51:31 +0200 [thread overview]
Message-ID: <20141014095131.GN8057@x2.net.home> (raw)
In-Reply-To: <5426D7F9.4030306@gmx.com>
On Sat, Sep 27, 2014 at 11:30:01AM -0400, JWP wrote:
>
> There are cases where we need to refresh the
> timestamps in the adjtime file without updating the
> drift factor.
>
> For example, with ntpd and an Eleven Minute Mode
> kernel, we need to call systohc at shutdown to
> facilitate drift correction. With the current
> behavior hwclock will clobber the drift factor to
> near zero, because the Hardware Clock and System
> Clock are synced by Eleven Minute Mode. What
> actually needs to be done is refresh the adjtime
> file timestamps and not calculate a new drift
> factor.
>
> Because it is a manual process to craft a good
> Hardware Clock drift factor, that is, there is no
> automated method that will produce a good drift
> factor, this patch changes the default drift
The ideal solution would be to generate event (for udev) in kernel
first time when Eleven Minute Mode modifies HW clock and send info
about the diff between HW and SYS time to userspace. Then it would be
possible to call something like "hwclock --set-drift <number>" from udev
rules. It means 11 minutes after reboot we will have nice usable
drift factor for the next system startup (--hctosys).
> calculation behavior to off, and it is turned on
> by using the --update option. Once we have a good
> drift factor for a given machine we do not want
> anything clobbering it, including an administrator
> forgetting to turn off recalculation. A system
> administrator should make a concious effort in
> telling hwclock with the --update option that
> (s)he wants to recalculate the drift factor.
> Without using the --update option with calibrate
> operations only the timestamps are refreshed in
> the adjtime file. With the --update option the old
> default behavior of refreshing the timestamps and
> updating the drift factor is performed.
The option "--update" seems to generic. It would be better
to use something like "--update-drift".
> + if (!update) {
> + /*
> + * Because the update option introduced new behavior to hwclock
> + * we warn when it is not used. After a reasonable introduction
> + * period this could be removed.
> + */
> + warnx(_("--update option is now required to update drift factor."));
I'd like to see something like
warnx(_("HW clock drift factor not updated by default. "
"See --update-drift for more details."));
and maybe it should be visible in verbose mode only. All we need is to
inform distro maintainers by ReleaseNotes rather than fill logs by
confusing messages.
> rc = manipulate_clock(show, adjust, noadjfile, set, set_time,
> hctosys, systohc, systz, startup_time, utc,
> - local_opt, testing, predict, get);
> + local_opt, update, testing, predict, get);
This is why we need refactoring. 15 arguments to function? Grrr..
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
next prev parent reply other threads:[~2014-10-14 9:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-27 15:16 [PATCH 0/7] hwclock patch cover letter JWP
2014-09-27 15:29 ` [PATCH 1/7] hwclock: hctosys drift compensation II JWP
2014-09-28 17:55 ` Sami Kerola
2014-09-29 16:48 ` JWP
2014-10-14 9:03 ` Karel Zak
2014-10-14 9:51 ` Sami Kerola
2014-10-14 10:27 ` Karel Zak
2014-10-16 23:21 ` JWP
2014-10-20 12:05 ` Karel Zak
2014-10-20 23:35 ` JWP
2014-10-21 9:38 ` Karel Zak
2014-09-27 15:29 ` [PATCH 2/7] hwclock: hctosys drift compensation II COMMENTS JWP
2014-09-27 15:29 ` [PATCH 3/7] hwclock: hctosys drift compensation II MAN JWP
2014-09-27 15:29 ` [PATCH 4/7] hwclock: persistent_clock_is_local JWP
2014-09-27 15:29 ` [PATCH 5/7] hwclock: persistent_clock_is_local MAN JWP
2014-09-27 15:30 ` [PATCH 6/7] hwclock: Add --update option JWP
2014-10-14 9:51 ` Karel Zak [this message]
2014-09-27 15:30 ` [PATCH 7/7] hwclock: Add --update option MAN JWP
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141014095131.GN8057@x2.net.home \
--to=kzak@redhat.com \
--cc=elseifthen@gmx.com \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).