> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
