>>> Lastly, the problem we are trying to solve seems to be mostly a
>>> non-issue, at least at boot, since hwclock can set the system
>>> clock properly before anything important happens. The more
>>> interesting problem is the one Richard brought up with APM.
>>> I think it goes like this:
>> 1) DST changeover is about to happen
>> 2) the machine goes into APM, before doing so the kernel in apm.c
>> computes a timezone offset to be used when coming out of APM.
>> 3) timezone changeover occurs due to DST going on or off.
>> 4) machine comes out of APM, read CMOS and applies wrong offset,
>> system time is now warped.
> No, this isn't what is happening. The problem is that some
> machines slow down the RTC measurment to the point where the
> measurement may be inaccurate by several seconds. Once the lid
> is closed, it's too late to do an accurate RTC measurement.
If I'm reading your description correctly, then my proposed patch
deals with that as well, so let me summarise:
1. The current situation is that the routine to read the time
from the RTC has no idea what timezone offset the RTC is
returning, and just returns the value it finds.
2. My patch, if used correctly, means that the routine to read
the time from the RTC will ALWAYS return UTC time, which is
what the kernel stores internally anyway.
3. As a result of applying the said patch, the apm routine only
needs to read the RTC as part of the "resume" step, and use
the time returned by doing so.
4. The said patch also deals with the boot-time race between
hwclock and fsck as recently reported in linux-kernel, and
which was the inspiration for the patch in the first place.
I will point out that my patch as supplied does NOT handle the WRITING
of the RTC, and the requirements for doing so need to be fully sorted
out before that can be written. Here's some possibilities:
1. The program calling the write RTC routine may assume that it
is to write either a UTC time or a local time to the RTC. As
far as hwclock is concerned, this decision is made by the
user when calling it, based on whether they supply the --utc
option or not.
2. If the program is writing a local time, it may specify one
where DST should be set, or one where it should not.
As I see it, any changes to the write RTC routine will need to be
coordinated with the author of hwclock and other similar programs.
>From my viewpoint, the ONLY implementation that would be safe would be
to make the existing write-RTC syscall return an error saying "Sorry,
this syscall is obsolete, and you will need to obtain an updated
program that uses the new syscall", then provide a new syscall that
assumes that the time passed to it is in UTC and unadjusts it in
precicely the opposite way to what the read-RTC syscall does.
However, I would suspect that such a measure would be unacceptable.
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/