lkml.org 
[lkml]   [1999]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] * RTC problem ???
    Hi Rafael.

    > 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/

    \
     
     \ /
      Last update: 2005-03-22 13:51    [W:2.670 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site