[arch-projects] [PATCH] Make hwclock --adjust as well as --systohc optional (FS#13684)

[Tom Gundersen]

On Mon, Mar 28, 2011 at 5:02 PM, Dave Reisner <d at falconindy.com> wrote:
> My hangup (which I should have mentioned in my previous email), is that
> the popular use case will always be to set the hwclock as we do right
> now. This changes default behavior without any fallback. The majority of
> users are inconvenienced and need to pick up on this change. I'll have
> to read up on pm-utils hooks to see if there's another approach that
> would also be suitable.

Thanks for the clarification Dave. I think you pinpoint the important
issue. If you are right that enabling hwclock will be the common
setup, then I agree with you. However, after discussing and thinking
about this I think most people should NOT enable hwclock.

These are the pros and cons of enabling hwclock:
 pro: relatively accurate system time even with no internet connection
(but why should anyone care about accurate system time if they are not
connected to other computers that they need to be in sync with? In
that case, the only purpose of the systemtime is to work as a
glorified wall clock.)
 con: if dual-boot, or ntpd is used hwclock will give a much less
reliable time than the user might assume (ntpd+hwclock is worse than
ntpd alone and worse than hwclock alone), and if localtime (so DST) is
used we might get total havoc.

In other words, the only people who should enable the hwclock daemon
are the ones who need system time to be more accurate than a regular
wall clock and who do not have a network connection so cannot use
ntpd. I guess that leaves people who want to use their hwclock as a
time source for an ntpd server on their local network where the local
network is not connected to the internet, and where they do not have a
proper time source.

I guess that many people are in a situation where they really should
not be stepping the hwclock without realising they are, so this change
would fix some weird issues for them. For the (hopefully few) who
genuinely need to use hwclock we'll have to write an announcement of
course.

Please let me know if anyone disagrees with my analysis, or if I have
overlooked something important.

If my assumption that using hwclock should be relatively rare, then I
think it would make sense to move it into a daemon for three reasons:
1) simplifies rc.sysinit
2) in general I think anything that does not need to be in rc.sysinit
should not be there (simpler the better)
3) given the choice, I'd rather we did not add more variables to
rc.conf, as removing them again in the future is a hassle

What do you think?

Tom