From: bryanh@giraffe-data.com (Bryan Henderson)
To: alessandro.zummo@towertech.it
Cc: mpm@selenic.com, benh@kernel.crashing.org, ak@muc.de,
akpm@osdl.org, torvalds@osdl.org, davem@davemloft.net,
kkojima@rr.iij4u.or.jp, lethal@linux-sh.org, paulus@samba.org,
ralf@linux-mips.org, rmk@arm.linux.org.uk,
linux-kernel@vger.kernel.org, smurf@debian.org,
stenn@whimsy.udel.edu, bunk@stusta.de, lamont@debian.org
Subject: Re: 11 minute RTC update (was Re: Remove RTC UIP)
Date: 30 Mar 2006 03:51:51 +0000 [thread overview]
Message-ID: <21892.bryanh@giraffe-data.com> (raw)
In-Reply-To: <20060329200758.2281149b@inspiron> (alessandro.zummo@towertech.it)
> udev will make a link from /dev/rtc to /dev/rtc0, but it would be
> fine if hwclock can check /dev/rtc0 itself in no device is specified
> on the cmd line.
I think one could argue as strongly that if the user has multiple
clocks and has not selected one as default by symlinking it to /dev/rtc,
then hwclock should make the user choose rather than pick one silently.
I'm ambivalent. I'll go ahead and make hwclock use /dev/rtc0 if there's
no /dev/rtc, unless I hear more arguments for the other side.
> It would be fine if hwclock can wait for the second to change only
> for a definite amount of time and then always try to set the time.
OK. N.B. the wait already times out, but in present code, that causes
the program to fail without setting anything. Also the --fast option
makes hwclock simply skip the whole synchronization process (meant for
use by people who don't find subsecond precision worth two seconds of
waiting at every boot).
I'll make hwclock proceed to set the clock when the synchronization
fails, but not try to recalculate the drift rate.
--
Bryan Henderson Phone 408-621-2000
San Jose, California
prev parent reply other threads:[~2006-03-30 4:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200603270920.k2R9KYYx007214@shell0.pdx.osdl.net>
[not found] ` <20060327111836.GA79131@muc.de>
[not found] ` <20060327163218.GD3642@waste.org>
[not found] ` <20060327190037.GB27030@muc.de>
[not found] ` <20060327211143.55ef7c4e@inspiron>
[not found] ` <1143512075.2284.2.camel@localhost.localdomain>
[not found] ` <20060329000215.683eb2d5@inspiron>
2006-03-29 0:03 ` 11 minute RTC update (was Re: Remove RTC UIP) Matt Mackall
2006-03-29 1:11 ` Alessandro Zummo
2006-03-29 1:21 ` Matt Mackall
2006-03-29 1:45 ` Alessandro Zummo
2006-03-29 16:49 ` Bryan Henderson
2006-03-29 18:07 ` Alessandro Zummo
2006-03-30 3:51 ` Bryan Henderson [this message]
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=21892.bryanh@giraffe-data.com \
--to=bryanh@giraffe-data.com \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=alessandro.zummo@towertech.it \
--cc=benh@kernel.crashing.org \
--cc=bunk@stusta.de \
--cc=davem@davemloft.net \
--cc=kkojima@rr.iij4u.or.jp \
--cc=lamont@debian.org \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=paulus@samba.org \
--cc=ralf@linux-mips.org \
--cc=rmk@arm.linux.org.uk \
--cc=smurf@debian.org \
--cc=stenn@whimsy.udel.edu \
--cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.