Messages in this thread | | | Date | Fri, 21 May 1999 15:04:12 +0100 (GMT) | From | Riley Williams <> | Subject | RE: i386/RTC: old problem, new solution? |
| |
Hi Nick, Ulrich.
>> I think you were assuming that the routines to determine the DST >> dates would need to be in the kernel as well, and I'd agree that >> suchlike routines would be far too much kernel bloat, but >> they're not needed for the purposes stated, as the above will >> achieve the same purpose.
> I would be worried about situations where these values are > specified in LILO for unattended boot. Systems don't change > their time zone very often, so RTCTZ would be OK, but one of > Linux's strength is that you can put it in a lights-out > environment. When it reboots, it has to have the correct time.
I have to agree here, as I've set up several suchlike systems, and it's for precicely that reason that I'm only discussing the issues here rather than working on a patch - this is something where the design HAS to be right before any coding starts.
> I don't know how many RTC chips provide a "DST in use" flag.
I can't speak for other architectures, but the common RTC chip on the ix86 architecture is the 148???? (I forget the rest of the number), and this has two flags of interest. The first is writable, and tells the chip whether or not to implement DST, and the second is read only and states whether the chip is currently returning DST or non-DST time. I don't have the technical docs handy, so I'll refer to these two flags as DSTenable and DSTinuse respectively in the text that follows.
As far as I can see it, the basic kernel algorithm would be something like the following pseudocode:
1. Define two kernel parameters, configurable at compile time, as follows:
__s16 rtctz = Non-DST timezone offset from UTC in minutes __s8 rtcdst = RTC's DST shift in minutes
Note that the latter will normally be +60 and can be regarded as being architecture specific.
2. Read the RTC registers, producing:
time_t sysclock = RTC time in time_t format boolean dstused = DSTenable && DSTinuse
3. Perform the following calculations:
sysclock -= 60 * RTCTZ if (dstused) { sysclock -= 60 * RTCDST }
Once that's been done, the kernel's system clock will reflect the UTC time indicated by the RTC if RTCTZ is set correctly, and since there's nothing in there that changes any register in the RTC, there's nothing that can affect the value the RTC returns.
> It would be a shame for the time to be fixed up correctly by > user space code when DST kicks in, only to be messed up by an > hour a week later when the power fails.
That's why I would only see this code referencing the flag in the RTC chip, and not tweaking it itself, as stated above.
> Maybe it's possible for the user-space code to be made aware of > the possibility of these flags having possibly messed up, but > you'd have to avoid situations such as some versions of Windows > have, where people working late on DST changeover night > (especially those booting multiple Windows versions) find their > clock changed multiple times.
That's primarily because Windows actually tweaks the RTC chip itself, and as I see it, that's one thing we MUST avoid doing.
Incidentally, one thing that's often overlooked is that we do NOT need to ensure that the shift in to and out of DST in the RTC occurs on the correct date. All we need is to know whether the time returned by the said chip is the DST or non-DST time, and what the DST shift used by that chip is, which is why the above pseudocode works.
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/
| |