Re: rtc again...

[Benjamin Herrenschmidt <bh40@calva.net>]

>
>I agree on the point if setting the timezone at boot, that's basically the
>only thing I would consider permissible. For the rest the RTC is running
>as is, and /dev/rtc gives you direct acces to the HW: no cooked values,
>you always end up losing when playing such games.

Ok. Then for this to work, we need to slightly change the boot code not
to call simply ppc_md.get_rtc_time(), but to also adjust it on pmac using
the pram timezone. That means adding a new ppc_md.fixup_time() used only
at boot, or adding a "fixup" parameter to ppc_mc.get_rtc_time() set to 0
in normal cases and to 1 on first call during boot.

>I do see some: principle of least surprise for people porting applications
>between PC and Mac. Minimize #ifdef noise in their sources...

Well, it's nice to save back the timezone to the xpram (the code Paul
added). But it's probably not good to do so from ppc_md.set_rtc_time().
So that would yet another #if/_MACH_Pmac hack...

>During Linux boot: read the time and offset from xpram and set xtime
>accordingly (preventing further timewarps by using do_sys_settimofday),
>then clear the timezone info in the RAM, and rewrite the clock so that it
>runs in UTC.

Clear the tz info in nvram ? why ? That would probably harm MacOS... And
I don't like writing to nvram when it's not necessary (nvram is a flash
on some machines). I would rather let the RTC run in local time and pass
localtime to userland, letting the user set the userland tool correctly
and so behave like other archs with local time RTC. So to resume, what I
need to fix is:

 - change ppc_md.get/set_rtc_time() to set and return the raw time from
the RTC
 - at boot, apply only once the offset from nvram, initialize sys_tz and
call do_sys_settimeofday()
 - Figure out a way to write back the timezone to nvram (since I think
sys_tz is updated by userland tools via settimeofday, isn't it ?) when
changed.

>Yes, this is strange, but the original error lies with Apple storing the
>time as local time while keeping also the timezone. I can understand and
>even agree on keeping the timezone and the DST flag in RAM, but then why
>the heck do you want to store the RTC in local time ? It only makes thing
>more complex around DST changes or when changing timezones when you
>travel. I thought Macs were about simplicity...

Macs are about simplicity, MacOS internals are not ;)

>Who uses FAT anyway ? I'm going to patch my kernels to kill sys_tz, now
>that I've come to the conclusion that its mere existence is an
>aberration... With an UTC clock, it's the only sensible solution ;-). But
>I don't suggest that everybody should do the same...

Hum...


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/