On 29 Mar 2006 16:49:41 +0000
[email protected] (Bryan Henderson) wrote:
> Concerning migration: ntpd presently tells the kernel to go into 11
> minute mode (I think technically, it tells the kernel that it is
> keeping the system time accurate and based on that information, the
> kernel takes the opportunity to keep the hardware clock accurate as
> well, but I think it's practically equivalent). So that suggests a
> migration path: Step 1: ntpd stops using that flag; Step 2: kernel
> issues warning if someone uses the flag; Step 3: kernel ignores the
> flag. For 1), ntpd issues a warning that nobody's minding the
> hardware clock unless you pass an option telling it to do hwclock
> --systohc or that you're handling the issue and ntpd needn't warn you
> about it. I like the latter better.
I agree with the latter option. I can write a patch for the kernel
to issue the warning.
> BTW, I am the maintainer of hwclock. This is the first I've heard of
> this discussion, but I have always been a supporter of the kernel
> getting out of the hardware clock maintenance business. What's this
> about multiple RTC's?
with the new subsystem that has recently been introduced you can
have more than one clock. the first one is /dev/rtc0 . 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.
One can have a mix of I2C clocks, x86 and maybe external radio
syncronized clocks all in the same subsystem.
But there's a problem. hwclock waits for the second
to change before setting the time. It may happen, with some i2c clocks,
that the oscillator is disabled and that it is started when the
time is set. Some other devices simply hang and may be restarted only by setting
the time.
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.
It may also happen that reading the time from the device returns
a failure due to a stopped clock. hwclock should ignore the error.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Turin, Italy
http://www.towertech.it
-
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]
