> Ok, now I get what your aiming at: Support just the hardware
> view of time.
> [snipped details on RTC chips and patch]
> In that case, the whole thing reduces to applying a pre-computed
> offset to whatever is read from the RTC.
To rephrase that, the whole thing basically reduces to making the RTC
appear to be storing UTC even if it isn't really doing so.
> Since we are going to read the RTC anyways on boot, then we
> could add such an offset if you want... but only at that point
> (ie. in time.c:time_init()). I don't think it is a good idea to
> fake the RTC time to userspace programs as it would probably
> confuse them.
Given the said patch, all userspace programs can safely assume that
the RTC is storing UTC time at all times.
> At first glance that is what your patch appears to be doing,
> right?
My patch as so far presented only deals with the READ half of the
equation. A complete patch would also need to deal with the WRITE half
thereof as well, and thereby provide a consistant view of the RTC to
userland irrespective of what's actually in it.
> Also, your rtctz script is a nifty way of extracting the
> timezone information when compiling, but I think I would be
> better if it was a boot parameter, say tzoffset=3600 where the
> offset is in seconds (so math is easy.)
It IS intended to be a boot parameter, but that parameter needs to
have a DEFAULT value, and what better default than the timezone offset
for the place where the kernel is compiled.
> Else, how do you distribute kernel binaries to different parts
> of the world? ;-)
As far as distribution kernels for people like RedHat, Caldera and the
like are concerned, I would assume that they will compile kernels set
to default to RTC = UTC, and have their install scripts set the
correct timezone parameter for the installation. Any other setting is
meaningless in that context.
> 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 problem there is the race that's involved. Basically, hwclock
needs to refer to a file on disk that it can't refer to until the
relevant partition has been mounted, and the relevant partition can't
be mounted until it's been fsck'd, which can't safely happen until
after hwclock's been run...
The cure for this vicious circle is to have some means for the kernel
to get an idea of the correct time BEFORE any of those need to run,
hence the proposed patch...
> 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,
> sytem time is now warped.
Given the patch I proposed, this becomes a non-issue, since the offset
is then calculated as part of the "read CMOS" step, so stage (2) has
no calculation to do, and stage 4's "read CMOS" step inherently
applies the correct offset.
> IMHO, the obvious solution would be to monitor the DST flag (if
> present) and if it changed during APM adjust the offset
> accordingly. Someone who knows where the DST flag is on the RTC
> should implement this ;-)
That's basically what my patch does...
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/