I seems to me (in summary) [since I started this thread :-) ]:
we can:
(a) Fix up time in the kernel to emulate UTC
(b) Fix up time in the kernel to emulates Local Time
Please also think about people who really run their RTC in UTC, who don't run
MacOS anymore, or who simply don't have a PowerMac.
It was never my intention to suggest otherwise - as (I'm sure) I'm on record
as saying - I've used all of 'em and have no particular favourites or axe to
grind :-)
I *would* like a working solution for those of us whose machines include
pmac and still need MacOS for some jobs.
Iain.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michael Schmitz <hidden> Date: 2000-08-08 17:08:25
quoted
quoted
(a) Fix up time in the kernel to emulate UTC
(b) Fix up time in the kernel to emulates Local Time
Please also think about people who really run their RTC in UTC, who don't run
MacOS anymore, or who simply don't have a PowerMac.
It was never my intention to suggest otherwise - as (I'm sure) I'm on record
as saying - I've used all of 'em and have no particular favourites or axe to
grind :-)
I *would* like a working solution for those of us whose machines include
pmac and still need MacOS for some jobs.
So what about setting the kernel internal time to local time including all
fixups at least on Powermacs (using the data passed by OF or read from
NVRAM) and to UTC (or more precisely, whatever the RTC is set to) on all
those where we cannot determine UTC and DST offsets from OF or NVRAM?
Next, agree on either returning local time or UTC, at any rate a time
without accounting for GMT and DST offset, via /dev/rtc so user space
tools won't notice a difference ? I'd vote for UTC format for /dev/rtc.
We do assume the user set up the clock properly (as in: actually bothered
to set the clock to UTC and define GMT and DST offset as apparently done
by the MacOS Date&Time control panel), and set hwclock to interpret the
time as UTC. Or the user set up the clock in local time (no DST offset)
and set hwclock to interpret the time as local time.
This way
- early log stamps and later ones agree on all those machines that let the
kernel figure out GMT and DST offset, and are off by at most the DST
offset if the clock is set to local time,
- we don't need any special case handling in hwclock.
Impossible?
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-08-08 17:41:57
So what about setting the kernel internal time to local time including all
fixups at least on Powermacs (using the data passed by OF or read from
NVRAM) and to UTC (or more precisely, whatever the RTC is set to) on all
those where we cannot determine UTC and DST offsets from OF or NVRAM?
Next, agree on either returning local time or UTC, at any rate a time
without accounting for GMT and DST offset, via /dev/rtc so user space
tools won't notice a difference ? I'd vote for UTC format for /dev/rtc.
I'm against changing the kernel time to something different on some
machines than on others. Let's resume my understanding of things:
The kernel keeps two things:
- xtime is the current time and should be UTC.
- sys_tz is the current timezone (usually set from userland)
When the kernel boots, it reads the time from the RTC. On pmac (or any
other machine that has a local time), that means that the kernel boots
with a wrong notion of time until that gets fixed from userland.
That's why I added that code that calculates the real UTC from the xpram.
It also initialize properly the sys_tz structure, since it's easy,
doesn't cost much, and I think it's always better to have a correct value
when we can ;) This would also allow some tools and/or installers to
"read" the timezone at boot in order to propose a default choice or such
things.
Now there are several problems:
- The first one, well hidden in kernel/time.c (generic code) is the call
to warp_time(). This is an awful hack that seem to be done because PCs
apparently also set the RTC to local time. This hack will cause the
kernel to "bump" the xtime the first time the syscall settimeofday() is
called is it is called with a valid timezone and a NULL timevalue.
With old broken behaviour, this code has the effect of causing the kernel
to "adjust" it's internal time that was wrongly set to local time to be
real UTC as soon as it is notified by userland of the real time zone.
Obviously, this code breaks us. We should probably change it so that a
global variables tells this code we have already inited sys_tz properly
and there's no need to warp.
- The second one is that ppc_md.get/set_rtc_time are passed (or return)
a time value independently of the timezone. That mean that they either do
no conversion and so it's the responsibility of the caller to "know" if
the RTC is in local time or UTC, or they do the conversion and so return
(and get passed) an UTC time. That's what I decided to do, so on
PowerMac, they do the adjustement from UTC to localtime and the opposite
inside those functions. Paul recently added code to also save the
timezone to the xpram. There's a small semantic problem with this code,
since it takes the time to set to the RTC as a parameter but uses the
global sys_tz. It should either use no parameter (and use only xtime/
sys_tz), or be passed both parameters. In this case, we can probably move
the init code that reads the initial time zone to the pmac_get_rtc_time() too.
- There's apparently a problem with the definition of the DST field of
sys_tz. The best way to handle this correctly is probably to see how
userland tools like hwclock use it. What is responsible for managing DST
on linux ? Is there a deamon for that ? A tool called from cron ?
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-08-08 22:44:34
On Tue, 8 Aug 2000, Benjamin Herrenschmidt wrote:
The kernel keeps two things:
- xtime is the current time and should be UTC.
^^^^^^
must
- sys_tz is the current timezone (usually set from userland)
Indeed, and it is used mostly (only?) by some filesystems which keep time
in local time.
When the kernel boots, it reads the time from the RTC. On pmac (or any
other machine that has a local time), that means that the kernel boots
with a wrong notion of time until that gets fixed from userland.
That's why I added that code that calculates the real UTC from the xpram.
It also initialize properly the sys_tz structure, since it's easy,
doesn't cost much, and I think it's always better to have a correct value
when we can ;) This would also allow some tools and/or installers to
"read" the timezone at boot in order to propose a default choice or such
things.
Now there are several problems:
- The first one, well hidden in kernel/time.c (generic code) is the call
to warp_time(). This is an awful hack that seem to be done because PCs
apparently also set the RTC to local time.
This is necessary for people who dual boot some M$ stuff (my PC is UTC and
it just works fine).
This hack will cause the
kernel to "bump" the xtime the first time the syscall settimeofday() is
called is it is called with a valid timezone and a NULL timevalue.
With old broken behaviour, this code has the effect of causing the kernel
to "adjust" it's internal time that was wrongly set to local time to be
real UTC as soon as it is notified by userland of the real time zone.
Obviously, this code breaks us. We should probably change it so that a
global variables tells this code we have already inited sys_tz properly
and there's no need to warp.
You could also call do_sys_settimeofday with correct tz from pram and a
null tv to adjust xtime and prevent userland from messing with it again
(faking the first call used to set timezone). do_sys_settimeofday is a
public symbol since it's used by sparc and alpha code (at least) for some
OSF and SunOS emulation.
Pushing this timezone setting policy to architecture dependant code is
another possibility, but the changes are bigger.
- The second one is that ppc_md.get/set_rtc_time are passed (or return)
a time value independently of the timezone. That mean that they either do
no conversion and so it's the responsibility of the caller to "know" if
the RTC is in local time or UTC, or they do the conversion and so return
(and get passed) an UTC time. That's what I decided to do, so on
PowerMac, they do the adjustement from UTC to localtime and the opposite
inside those functions. Paul recently added code to also save the
timezone to the xpram. There's a small semantic problem with this code,
since it takes the time to set to the RTC as a parameter but uses the
global sys_tz. It should either use no parameter (and use only xtime/
sys_tz), or be passed both parameters. In this case, we can probably move
the init code that reads the initial time zone to the pmac_get_rtc_time() too.
I'm slightly lost :-(. But whether the clock is in UTC or not is a
parameter (defined in /etc/sysconfig/clock or another system configuration
file), so I think that translating to/from UTC when setting the clock is a
purely userland job and set/get_rtc_time should never have to handle this.
- There's apparently a problem with the definition of the DST field of
sys_tz. The best way to handle this correctly is probably to see how
userland tools like hwclock use it. What is responsible for managing DST
on linux ? Is there a deamon for that ? A tool called from cron ?
No, AFAICT nothing bothers with it, only the clock program at boot.
First it is 99% a userland problem: just set export TZ=UTC or any path in
/usr/share/zoneinfo and all dates will appear as if you were in this
timezone (try date or ls -l).
The translation between UTC and localtime is performed in the C library,
using the TZ environment variable or /etc/localtime, and it will know when
to switch between DST and non DST.
The last problem is updating the clock through NTP when the RTC is running
in local time. Since these are generally small corrections, there are
solutions (but the comments of the i386 version say that it is buggy :-().
Until now I've found a single place where sys_tz.dsttime is used in the
kernel: fs/fat/misc.c when converting between Unix and FAT timestamps.
Interestingly it's used only in one direction, so it definitely looks like
a bug. Some other filesystems (affs/hfs/ncpfs/ufs) use the timezone
information but not the dst field, making FAT time handling look even
buggier.
Regards,
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
- The second one is that ppc_md.get/set_rtc_time are passed (or return)
a time value independently of the timezone. That mean that they either do
no conversion and so it's the responsibility of the caller to "know" if
the RTC is in local time or UTC, or they do the conversion and so return
(and get passed) an UTC time. That's what I decided to do, so on
PowerMac, they do the adjustement from UTC to localtime and the opposite
inside those functions. Paul recently added code to also save the
timezone to the xpram. There's a small semantic problem with this code,
since it takes the time to set to the RTC as a parameter but uses the
global sys_tz. It should either use no parameter (and use only xtime/
sys_tz), or be passed both parameters. In this case, we can probably move
the init code that reads the initial time zone to the pmac_get_rtc_time() too.
Personally, I think UTC <-> local time conversion should be handled in
userland. Both hwclock and clock can handle both local time and UTC just
fine.
Does Mac OS handle different timezone information in xpram well? Timezone
information is saved in xpram but it's also saved in some of config files.
So, it appears to me that Mac OS will get confused or ignore or delete the
timezone setting in xpram if it doesn't agree with the config file.
Takashi Oe
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-08-09 08:44:22
I'm slightly lost :-(. But whether the clock is in UTC or not is a
parameter (defined in /etc/sysconfig/clock or another system configuration
file), so I think that translating to/from UTC when setting the clock is a
purely userland job and set/get_rtc_time should never have to handle this.
The problem is that those functions are in-kernel, and without proper
conversion, they could put incorrect time in the RTC. Those are called by
/dev/rtc on macintosh, additionally, get_rtc_time() is called at boot,
and set_rtc_time() used to be called regulary (the famous code I #if'ed out).
So if it's a userland-only thing, then the set_time() must be removed
since the kernel can't know if the RTC is UTC or local time. Except if we
decide that on PowerMac, we always follow Apple layout (to be compatible
with MacOS X) and implement the UTC/local conversion inside those so they
always expose UTC times to the kernel.
No, AFAICT nothing bothers with it, only the clock program at boot.
And the fat file system (see below)
First it is 99% a userland problem: just set export TZ=UTC or any path in
/usr/share/zoneinfo and all dates will appear as if you were in this
timezone (try date or ls -l).
The translation between UTC and localtime is performed in the C library,
using the TZ environment variable or /etc/localtime, and it will know when
to switch between DST and non DST.
The last problem is updating the clock through NTP when the RTC is running
in local time. Since these are generally small corrections, there are
solutions (but the comments of the i386 version say that it is buggy :-().
I see no solution to this problem but do the conversion in kernel. Also,
whatever userland does after boot, it's nice to have a correct time and
timezone as early as possible, especialy if it takes only a few lines of
kernel code to grab the correct MacOS values.
I don't see why we shouldn't have those in-kernel get/set time do the
conversion, at least on pmac. I see no point of trying to mimmic the PC
behaviour here. The Mac clock is supposed to run local time, but we do
have the timezone info in a known location in pram, I see no reason to
let users (on pmac at least) store UTC in the RTC. CHRP/PReP are a
different matter.
Now, I need to check how this interracts with our pmac /dev/rtc so that
userland "see" a consistent kernel interface. This new /dev/rtc driver
means userland will go thry the ppc_md.set/get time functions when using
this driver (the old "clock" program used to directly talk to Cuda/PMU
via /dev/adb, I wanted to get rid of that).
Until now I've found a single place where sys_tz.dsttime is used in the
kernel: fs/fat/misc.c when converting between Unix and FAT timestamps.
Interestingly it's used only in one direction, so it definitely looks like
a bug. Some other filesystems (affs/hfs/ncpfs/ufs) use the timezone
information but not the dst field, making FAT time handling look even
buggier.
Yep. My understanding (and that's also how MacOS uses it) is that the DST
correction is _included_ in the timezone offset, the dst field beeing
just an indication. So yes, FAT is probably broken.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-08-09 08:48:39
Personally, I think UTC <-> local time conversion should be handled in
userland. Both hwclock and clock can handle both local time and UTC just
fine.
If we do that this way, we can't have proper in-kernel NTP update of the
RTC without a hack that let it only "correct" for less than 1 hour.
Does Mac OS handle different timezone information in xpram well? Timezone
information is saved in xpram but it's also saved in some of config files.
So, it appears to me that Mac OS will get confused or ignore or delete the
timezone setting in xpram if it doesn't agree with the config file.
It used to be only in xpram. Recent MacOS also have a prefs file, I have
to check what happens when this file is out of sync with the xpram.
Saving the tz to xpram also makes sure the kernel is fine at boot accross
multiple boots.
It may be a "cultural" difference due to my years of MacOS background,
but rather than having userland set the timezone, I'd personally rather
see userland read the kernel timezone coming from xpram, and set the
appropriate userland env. vars depending on this timezone (especially
useful for portables). Well, that's my 2 cents, of course, nobody will
agree wit me ;)
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Martin Costabel <hidden> Date: 2000-08-09 11:32:45
Benjamin Herrenschmidt wrote:
quoted
I'm slightly lost :-(. But whether the clock is in UTC or not is a
parameter (defined in /etc/sysconfig/clock or another system configuration
file), so I think that translating to/from UTC when setting the clock is a
purely userland job and set/get_rtc_time should never have to handle this.
The problem is that those functions are in-kernel, and without proper
conversion, they could put incorrect time in the RTC. Those are called by
/dev/rtc on macintosh, additionally, get_rtc_time() is called at boot,
and set_rtc_time() used to be called regulary (the famous code I #if'ed out).
So if it's a userland-only thing, then the set_time() must be removed
since the kernel can't know if the RTC is UTC or local time. Except if we
decide that on PowerMac, we always follow Apple layout (to be compatible
with MacOS X) and implement the UTC/local conversion inside those so they
always expose UTC times to the kernel.
Do I understand this right: As a Pmac user, I have to set "UTC=yes" in
/etc/sysconfig/clock, and then everything will be working correctly? So
only those developers who want to lose their sanity by trying to hack
the kernel time routines have to know that the Pmac CMOS clock is
actually running in localtime, whereas for everyone else, kernel and
userland, it appears to run in UTC?
This makes sense. It also explains the recent confusion: I think I used
to have UTC=yes, until with the recent introduction of rtc.c, everyone
was claiming that the Pmac CMOS clock runs in localtime, so I switched
to UTC=false.
It would be nice to have the same system in all the kernel trees. Right
now, the 5 kernel trees at penguinppc.org have 4 different versions of
the {s|g}et_rtc_time() routines in arch/ppc/kernel/pmac_time.c. In the
bitkeeper-devel kernel, these 2 routines aren't even compatible: If you
say "hwclock --systohc" and then "hwclock --hctosys", you don't get the
same time as before.
<2 reboots later>
This is driving me nuts! What I wrote above worked nicely for a
bitkeeper-2.2.17 kernel with arch/ppc/kernel/pmac_time.c from pmac-benh.
I now tried it with a pmac-devel 2.4.0-test6 kernel which has the same
logic of offsets get_rtc_time() in pmac_time.c, if I am able to read.
But it does not give the same result! System time is off by 2 hours. So
this kernel wants "UTC=false"... And I am back to square one: Impossible
to configure my system using RTC and the new hwclock in such a way that
a 2.2.17 kernel and a 2.4.0 kernel boot up to the same system time.
</giving up>
--
Martin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-08-09 13:50:09
On Wed, 9 Aug 2000, Benjamin Herrenschmidt wrote:
quoted
I'm slightly lost :-(. But whether the clock is in UTC or not is a
parameter (defined in /etc/sysconfig/clock or another system configuration
file), so I think that translating to/from UTC when setting the clock is a
purely userland job and set/get_rtc_time should never have to handle this.
The problem is that those functions are in-kernel, and without proper
conversion, they could put incorrect time in the RTC. Those are called by
/dev/rtc on macintosh, additionally, get_rtc_time() is called at boot,
and set_rtc_time() used to be called regulary (the famous code I #if'ed out).
No, the code was wrong, it should only be called if the kernel PLL is
running, i.e. if STA_UNSYNC is 0. Since STA_UNSYNC is set at boot, it
should never be called by default. And this code should also only track
small drifts, i.e., only set the minutes and seconds for NTP.
So if it's a userland-only thing, then the set_time() must be removed
since the kernel can't know if the RTC is UTC or local time. Except if we
decide that on PowerMac, we always follow Apple layout (to be compatible
with MacOS X) and implement the UTC/local conversion inside those so they
always expose UTC times to the kernel.
quoted
No, AFAICT nothing bothers with it, only the clock program at boot.
And the fat file system (see below)
Some other file systems bother with the the zone too, and that one is only
set on every reboot on your average Linux machine...
quoted
First it is 99% a userland problem: just set export TZ=UTC or any path in
/usr/share/zoneinfo and all dates will appear as if you were in this
timezone (try date or ls -l).
The translation between UTC and localtime is performed in the C library,
using the TZ environment variable or /etc/localtime, and it will know when
to switch between DST and non DST.
The last problem is updating the clock through NTP when the RTC is running
in local time. Since these are generally small corrections, there are
solutions (but the comments of the i386 version say that it is buggy :-().
I see no solution to this problem but do the conversion in kernel. Also,
whatever userland does after boot, it's nice to have a correct time and
timezone as early as possible, especialy if it takes only a few lines of
kernel code to grab the correct MacOS values.
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.
I don't see why we shouldn't have those in-kernel get/set time do the
conversion, at least on pmac. I see no point of trying to mimmic the PC
behaviour here.
I do see some: principle of least surprise for people porting applications
between PC and Mac. Minimize #ifdef noise in their sources...
The Mac clock is supposed to run local time, but we do
have the timezone info in a known location in pram, I see no reason to
let users (on pmac at least) store UTC in the RTC. CHRP/PReP are a
different matter.
I happen to disagree, it depends on what will happen with MacOS and the
schizophreny of having timezone parameters in the NVRAM and in the OS
config. I don't know MacOS so I might be wrong, but there might be a
solution running if MacOS does things in a sensible way (preferences
override RAM settings, which is the right thing to do when you are
travelling around the world with your notebook, and also if you have to
zap the RAM for some reason):
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.
Under MacOS: use MacOS preferences to set the timezone at least once,
hopefully when it boots it will either a) leave the RTC as is (making it
work properly as an UTC clock), or b) warp the clock and save the offsets
in RAM.
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...
Now, I need to check how this interracts with our pmac /dev/rtc so that
userland "see" a consistent kernel interface. This new /dev/rtc driver
means userland will go thry the ppc_md.set/get time functions when using
this driver (the old "clock" program used to directly talk to Cuda/PMU
via /dev/adb, I wanted to get rid of that).
quoted
Until now I've found a single place where sys_tz.dsttime is used in the
kernel: fs/fat/misc.c when converting between Unix and FAT timestamps.
Interestingly it's used only in one direction, so it definitely looks like
a bug. Some other filesystems (affs/hfs/ncpfs/ufs) use the timezone
information but not the dst field, making FAT time handling look even
buggier.
Yep. My understanding (and that's also how MacOS uses it) is that the DST
correction is _included_ in the timezone offset, the dst field beeing
just an indication. So yes, FAT is probably broken.
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...
Regards,
Gabriel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
- The first one, well hidden in kernel/time.c (generic code) is the call
to warp_time(). This is an awful hack that seem to be done because PCs
apparently also set the RTC to local time. This hack will cause the
It depends: Linux-only PCs are encouraged to run the RTC in UTC, while you
have to run the RTC in local time if you want Linux to coexist with some other
OSses, e.g. those from Redmond.
Which one is used is specified in user space. On Debian (I'm using 2.1 on an
isa32 box right here), I have the lines
# Set GMT="-u" if your system clock is set to GMT, and GMT="" if not.
GMT="-u"
in /etc/default/rcS.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Until now I've found a single place where sys_tz.dsttime is used in the
kernel: fs/fat/misc.c when converting between Unix and FAT timestamps.
Interestingly it's used only in one direction, so it definitely looks like
a bug. Some other filesystems (affs/hfs/ncpfs/ufs) use the timezone
information but not the dst field, making FAT time handling look even
buggier.
Yep. My understanding (and that's also how MacOS uses it) is that the DST
correction is _included_ in the timezone offset, the dst field beeing
just an indication. So yes, FAT is probably broken.
I agree that the way FAT does appear to buggy, but it would be better to
use *minuteswest and *dsttime in kernel as in userland IMHO. When
localtime() in /usr/include/time.h is called, two global variables are
set. One is timezone and the other is daylight, and here is how it works:
$ cat t.c
#include <stdio.h>
#include <time.h>
int main()
{
time_t gmt;
struct tm cur_tm;
gmt = time( NULL );
cur_tm = *gmtime( &gmt );
printf("UTC %02d:%02d:%02d\n",cur_tm.tm_hour,cur_tm.tm_min,cur_tm.tm_sec);
cur_tm = *localtime( &gmt );
printf("local %02d:%02d:%02d\n",cur_tm.tm_hour,cur_tm.tm_min,cur_tm.tm_sec);
printf("timezone = %d\n", timezone);
printf("daylight = %d\n", daylight);
return 0;
}
$ gcc -o t t.c
$ ./t
UTC 14:11:31
local 09:11:31
timezone = 21600
daylight = 1
$
As you can see, "timezone" does not include the DST offset, so any
applications which care need to use "daylight" flag. Since the kernel's
struct timezone has two equivalent fields, I would think it's easier to
maintain timezone related codes if its usage are also somewhat equivalent
to userland. Otherwise, I see no point in having a separate useless DST
info.
Takashi Oe
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-08-09 15:25:41
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...
Personally, I think UTC <-> local time conversion should be handled in
userland. Both hwclock and clock can handle both local time and UTC just
fine.
If we do that this way, we can't have proper in-kernel NTP update of the
RTC without a hack that let it only "correct" for less than 1 hour.
Hmm, I don't really understand this NTP update problem. Does NTP even
work when the system time is off by more than 1 hour?
quoted
Does Mac OS handle different timezone information in xpram well? Timezone
information is saved in xpram but it's also saved in some of config files.
So, it appears to me that Mac OS will get confused or ignore or delete the
timezone setting in xpram if it doesn't agree with the config file.
It used to be only in xpram. Recent MacOS also have a prefs file, I have
to check what happens when this file is out of sync with the xpram.
Ok, at least on Mac OS 8.6, it looks okay. At each boot, Mac OS honors
the timezone setting in xpram over its configuration files, and it always
assumes that RTC is in localtime as previously noted. Now, the OS doesn't
update its configuration files like for Location Manager, so users will
have to deal with it, and that's okay.
Saving the tz to xpram also makes sure the kernel is fine at boot accross
multiple boots.
How does kernel know when to update the tz so that it can save the info to
xpram? Since do_settimeofday() is not necessarily called when tz is
changed, we'd have to save the tz to xpram every time do_settimeofday() is
called even when tz is not at all changed. Or is the xpram update only
done when *set_rtc() is called? How do you know when to set DST flag on
xpram?
Isn't it better to have a little userland app do the xpram manipulation?
It may be a "cultural" difference due to my years of MacOS background,
but rather than having userland set the timezone, I'd personally rather
see userland read the kernel timezone coming from xpram, and set the
appropriate userland env. vars depending on this timezone (especially
useful for portables). Well, that's my 2 cents, of course, nobody will
agree wit me ;)
/dev/rtc aside, kernel only communicates through UTC, and timezone
manipulation is best done in userland especially for portables. When you
go from one timezone to another, it requires some sort of userland
intervention to get clock right anyway.
Let's say /dev/rtc gives raw machine value and since Mac OS requires it to
be localtime for P'Mac let me assume /dev/rtc gives localtime which is
consistent with xpram timezone info. As long as RTC and xpram timezone
info is consistent (it does'nt have to be the correct timezone where the
machine happens to be at the time), kernel can always figure out what UTC
is at very early boot time. If /dev/rtc time and kernel UTC derived
localtime (via /etc/localtime) do not agree, we know something has
happened and we can decide or ask users to set xpram timezone info (via
/dev/nvram or whatever) or change /etc/localtime link or whatever at boot
time or user specified time. And, if /dev/rtc time and kernel UTC derived
localtime do agree, all is well and we have nothing to do. Either way,
there is nothing for kernel to decide. See?
Takashi Oe
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
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.
Or let ppc_md.time_init() return offset between ppc_md.get_rtc_time()
value and UTC and use the offset in time_init() as I proposed
previously...
Takashi Oe
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-08-09 17:04:35
quoted
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.
Or let ppc_md.time_init() return offset between ppc_md.get_rtc_time()
value and UTC and use the offset in time_init() as I proposed
previously...
Yes, that would work. But when the offset is non-NULL we must also make
sure we call do_settimeofday() to disable the warp hack in kernel/time.c
Saving the timezone value to xpram is another issue. It could be done
from userland but we currently don't have userland tool that properly
access the xpram portion of the nvram. I did plan to add some ioctls to /
dev/nvram for it to return the location of the various nvram partitions,
looks like it will be time to actually implement them... Also, the
userland tool will have to be written...
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-08-09 22:13:16
On Wed, 9 Aug 2000, Benjamin Herrenschmidt wrote:
quoted
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 strongly suspect that we might want a single rtc access function in
ppc_md and add a first parameter telling what we want it to do, the second
being a pointer to a tv_sec, and perhaps more parameters.
I have problems for example with repeatability of boot-time timebase
frequency measurements (yes 2-3 ppm are extremely important for me)
which could be solved by yet another entry in ppc_md but I don't want it.
The solution would be to read the rtc and return the timebase value at the
time the second changes.
This ppc_md.rtc_access should provide the following functions or something
equivalent,
PPC_RTC_READ_TIME,
PPC_RTC_WRITE_TIME,
PPC_RTC_WRITE_MMSS (for NTP/adjtime adjustments),
PPC_RTC_CALIBRATE_TB (needed for some machines, measure as precisely as
possible the timebase difference between 2 second transitions, this means
on PreP for example setting the NVRAM pointer to the seconds byte and
repeatedly reading it instead of rereading the whole year to seconds every
time),
This last function could also be performed by returning the timebase in
the READ_TIME function as an extra parameter. The best solution is the one
which gives the minimal permanent kernel size, __init code size is
irrelevant.
quoted
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...
What use does it have if no daemon will change the timezone anyway ?
Your time offset will be updated on the fly (at least for newly
forked processes), but the kernel sys_tz won't. This might actually be
construed as a feature, imagine running make in a filesystem with local
time filestamps around a backward DST change...
AFAICT for example Win98 will change the RTC only on reboot when it
detects that the DST setting has changed since last reboot. And even that
does not work properly (that's what a colleague told me, so take it with a
grain of salt). This maybe because time warps would confuse running (M$ of
course) applications, and anyway you are not supposed to leave it running
overnight, it will anyway crash for you if you forget to shutdown ;-)
How does MacOS handle DST changes (on the fly or only at reboot) ?
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
You never (well hardldy ever) pass localtime to userland in Unix and
that's a big big big plus, each process/user can set TZ as it wishes. IOW
the value of sys_tz is at best a system wide default but is not imposed to
anybody. Here at the telescope on all Linux machines, /etc/localtime is
set as UTC, but then I set TZ=Europe/Madrid in my .profile to avoid too
much confusion with my PC which has localtime set to Europe/Madrid. And
right now I am running a shell with TZ set to Pacific/Tahiti to believe
that I'm on holiday ;-)
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.
I'm not sure on this last point, the rest looks fine and correct.
quoted
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 ;)
;-) I see...
quoted
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...
Done and booted (although I will probably orphan the changeset).
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-08-09 22:46:14
On Wed, 9 Aug 2000, Takashi Oe wrote:
On Wed, 9 Aug 2000, Benjamin Herrenschmidt wrote:
quoted
quoted
Personally, I think UTC <-> local time conversion should be handled in
userland. Both hwclock and clock can handle both local time and UTC just
fine.
If we do that this way, we can't have proper in-kernel NTP update of the
RTC without a hack that let it only "correct" for less than 1 hour.
Hmm, I don't really understand this NTP update problem. Does NTP even
work when the system time is off by more than 1 hour?
Oh yes, it will simply call settimeofday if the error is large or
adjtimex if it's small enough to drift smoothly in a reasonable time.
The question is, will it update the RTC correctly ?
It depends on many things, my PC clock was off by 20 minutes and it did
not update the RTC (limit is about 15 minutes since there are half hours
time zones). I had to use hwclock --systohc --utc to set it up once I had
ntp running and locked on a server, now te kernel automatically takes care
of it.
quoted
It used to be only in xpram. Recent MacOS also have a prefs file, I have
to check what happens when this file is out of sync with the xpram.
Ok, at least on Mac OS 8.6, it looks okay. At each boot, Mac OS honors
the timezone setting in xpram over its configuration files, and it always
assumes that RTC is in localtime as previously noted. Now, the OS doesn't
update its configuration files like for Location Manager, so users will
have to deal with it, and that's okay.
Confused, but I've hardly ever even seen a Mac.
How does kernel know when to update the tz so that it can save the info to
xpram? Since do_settimeofday() is not necessarily called when tz is
changed, we'd have to save the tz to xpram every time do_settimeofday() is
called even when tz is not at all changed. Or is the xpram update only
done when *set_rtc() is called? How do you know when to set DST flag on
xpram?
Isn't it better to have a little userland app do the xpram manipulation?
Is it actually even necessary to manipulate it. Once the kernel clock is
in UTC, everything is userland under Unix. If MacOS detects that DST has
changed after a reboot, let it handle this, as long as it allows to find
UTC from RTC and xpram everything is fine.
quoted
It may be a "cultural" difference due to my years of MacOS background,
but rather than having userland set the timezone, I'd personally rather
see userland read the kernel timezone coming from xpram, and set the
appropriate userland env. vars depending on this timezone (especially
useful for portables). Well, that's my 2 cents, of course, nobody will
agree wit me ;)
/dev/rtc aside, kernel only communicates through UTC, and timezone
manipulation is best done in userland especially for portables. When you
go from one timezone to another, it requires some sort of userland
intervention to get clock right anyway.
Indeed...
Let's say /dev/rtc gives raw machine value and since Mac OS requires it to
be localtime for P'Mac let me assume /dev/rtc gives localtime which is
consistent with xpram timezone info. As long as RTC and xpram timezone
info is consistent (it does'nt have to be the correct timezone where the
machine happens to be at the time), kernel can always figure out what UTC
is at very early boot time. If /dev/rtc time and kernel UTC derived
localtime (via /etc/localtime) do not agree, we know something has
happened and we can decide or ask users to set xpram timezone info (via
Why ? On a portable it may simply mean that you are away and set
/etc/localtime to your new zone or anything else, but I'd rather keep
the filesystem timestamps on my FAT/hfs partitions to the local
timestamps of my default location. As long as I don't boot MacOS while I'm
away there is perhaps no reason to change the xpram offset...
/dev/nvram or whatever) or change /etc/localtime link or whatever at boot
time or user specified time. And, if /dev/rtc time and kernel UTC derived
localtime do agree, all is well and we have nothing to do. Either way,
there is nothing for kernel to decide. See?
No policy in the kernel in indeed a good guideline.
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-08-09 22:48:02
I strongly suspect that we might want a single rtc access function in
ppc_md and add a first parameter telling what we want it to do, the second
being a pointer to a tv_sec, and perhaps more parameters.
[.../...]
This last function could also be performed by returning the timebase in
the READ_TIME function as an extra parameter. The best solution is the one
which gives the minimal permanent kernel size, __init code size is
irrelevant.
Ok.
What use does it have if no daemon will change the timezone anyway ?
Well, when travelling with a PowerBook, you tend to regulary change the
timezone, and you like the kernel to remember what it was ;) Paul added
the write back of the sys_tz, so I beleive he has some userland tool to
set it too, Paul ?
With this current code, any write to our pmac-specific /dev/rtc will
cause ppc_md.set_rtc_time to update both the RTC and the xpram sys_tz.
So either we make a userland tool for that, or eventually add such a
feature to pmud along with other PowerBook-specific tasks, accessing /
dev/nvram directly, or we find a way to make sure updates to sys_tz are
written back to nvram. I was not specifically thinking about results of a
DST change. We could eventually add this code along with other nvram
write code (for flash based nvram) in the restart/shutdown routines if we
don't want to do it from every ppc_md.set
How does MacOS handle DST changes (on the fly or only at reboot) ?
On the fly.
You never (well hardldy ever) pass localtime to userland in Unix and
that's a big big big plus, each process/user can set TZ as it wishes. IOW
the value of sys_tz is at best a system wide default but is not imposed to
anybody. Here at the telescope on all Linux machines, /etc/localtime is
set as UTC, but then I set TZ=Europe/Madrid in my .profile to avoid too
much confusion with my PC which has localtime set to Europe/Madrid. And
right now I am running a shell with TZ set to Pacific/Tahiti to believe
that I'm on holiday ;-)
Ok, I understand that. That's indeed a nice feature. Changing the
"global" timezone is specifically useful for portables. You can consider
it as the machine's physical location instead of a kind of "global" timezone.
Done and booted (although I will probably orphan the changeset).
Saving the timezone value to xpram is another issue. It could be done
from userland but we currently don't have userland tool that properly
access the xpram portion of the nvram. I did plan to add some ioctls to /
dev/nvram for it to return the location of the various nvram partitions,
looks like it will be time to actually implement them... Also, the
userland tool will have to be written...
I had a xpram manipulation tool, so I modified it a bit. Also, I added an
ioctl to drivers/macintosh/nvram.c.
Please have a look at them. Are these what you had in mind?
Takashi Oe
Kernel mods:
--- linux-2.4.0-test4/include/asm-ppc/nvram.h Tue May 2 15:05:40 2000+++ linux-nubus/include/asm-ppc/nvram.h Wed Aug 9 17:44:23 2000
@@ -38,12 +38,14 @@pmac_nvram_NR/* MacOS Name Registry partition */};+#ifdef __KERNEL__/* Return partition offset in nvram */externintpmac_get_partition(intpartition);/* Direct access to XPRAM */externu8pmac_xpram_read(intxpaddr);externvoidpmac_xpram_write(intxpaddr,u8data);+#endif /* __KERNEL__ *//* Some offsets in XPRAM */#define PMAC_XPRAM_MACHINE_LOC 0xe4
@@ -51,9 +53,12 @@/* Machine location structure in XPRAM */structpmac_machine_location{-u32latitude;/* 2+30 bit Fractional number */-u32longitude;/* 2+30 bit Fractional number */-u32delta;/* mix of GMT delta and DLS */+unsignedintlatitude;/* 2+30 bit Fractional number */+unsignedintlongitude;/* 2+30 bit Fractional number */+unsignedintdelta;/* mix of GMT delta and DLS */};++/* /dev/nvram ioctls */+#define PMAC_NVRAM_GET_OFFSET _IOWR('p', 0x40, int) /* Get NVRAM partition offset */#endif---linux-2.4.0-test4/drivers/macintosh/nvram.cTueJun2015:58:422000+++linux-nubus/drivers/macintosh/nvram.cWedAug916:44:502000
From: Benjamin Herrenschmidt <hidden> Date: 2000-08-09 23:48:57
quoted
Saving the timezone value to xpram is another issue. It could be done
from userland but we currently don't have userland tool that properly
access the xpram portion of the nvram. I did plan to add some ioctls to /
dev/nvram for it to return the location of the various nvram partitions,
looks like it will be time to actually implement them... Also, the
userland tool will have to be written...
I had a xpram manipulation tool, so I modified it a bit. Also, I added an
ioctl to drivers/macintosh/nvram.c.
Please have a look at them. Are these what you had in mind?
Ah, sometimes I'd like to have more often access to my linux boxes ;)
Looks nice, I'll test that asap (probably sometimes this week-end) and
push along with the other fixes.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: William Blew <hidden> Date: 2000-08-10 00:00:50
On Thu, 10 Aug 2000, Gabriel Paubert wrote:
On Wed, 9 Aug 2000, Benjamin Herrenschmidt wrote:
How does MacOS handle DST changes (on the fly or only at reboot) ?
If I remember correctly this spring my MacOS 9 changed it on the fly.
--
William Blew, wblew@home.com
Gamer by Choice, Geek by Birth
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Gabriel Paubert <hidden> Date: 2000-08-10 03:08:10
On Thu, 10 Aug 2000, Benjamin Herrenschmidt wrote:
quoted
This last function could also be performed by returning the timebase in
the READ_TIME function as an extra parameter. The best solution is the one
which gives the minimal permanent kernel size, __init code size is
irrelevant.
Ok.
So now it might be time to start coding :-)
quoted
What use does it have if no daemon will change the timezone anyway ?
Well, when travelling with a PowerBook, you tend to regulary change the
timezone, and you like the kernel to remember what it was ;) Paul added
the write back of the sys_tz, so I beleive he has some userland tool to
set it too, Paul ?
Perhaps timeconfig does this.
BTW, from hwclock manual on my PC about DST:
locality at the present time. In practice, the DST part
of the timezone value is almost never used, so if the geo-
graphical part were to be set to its correct value, the
users of the timezone value would actually compute the
wrong local time.
Therefore, hwclock violates the definition of the kernel's
timezone value and always sets the DST part to zero. If
DST is supposed to be in effect, hwclock simply adds an
hour to the geographical part.
So it's still another convention, where as usual theory and practice
are different, but in practice match MacOS RTC. My head hurts...
Given the broken FAT code which needs fixing, couldn't we simply decide
that DST in the kernel is merely informative and that
localtime = UTC - sys_tz.minutes_west (hopefully I got the sign right).
With this current code, any write to our pmac-specific /dev/rtc will
cause ppc_md.set_rtc_time to update both the RTC and the xpram sys_tz.
So either we make a userland tool for that, or eventually add such a
feature to pmud along with other PowerBook-specific tasks, accessing /
dev/nvram directly, or we find a way to make sure updates to sys_tz are
written back to nvram. I was not specifically thinking about results of a
DST change. We could eventually add this code along with other nvram
write code (for flash based nvram) in the restart/shutdown routines if we
don't want to do it from every ppc_md.set
I have no strong feeling about this, maybe I'll have the day I can afford
a PowerBook ;-)
quoted
How does MacOS handle DST changes (on the fly or only at reboot) ?
On the fly.
Ok, that changes a few things in the equation. But I would not like to
type `make' around a DST change on a filesystem which uses local time.
Ok, I understand that. That's indeed a nice feature. Changing the
"global" timezone is specifically useful for portables. You can consider
it as the machine's physical location instead of a kind of "global" timezone.
I still don't get it. For my portable physical location would be my house,
and I might change TZ or /etc/localtime when I travel, but if I have a
filesystem which uses localtime, I would prefer these to be correct for
the most frequent case: when I'm at home. Otherwise it becomes a nightmare
when you have a mixture of local time and UTC filesystems:
- I'm in California, I do a copy from ext2 to hfs with local time set to
Pacific coast (GMT-8).
ext2 timestamp 6 pm, hfs time 10 am
I reboot under MacOS (why not), modify the file, let us
say that it takes an hour so the modification time is now 11am
Reboot under Linux, ls shows ext2 at 10 am, hfs at 11am
- now I go back to Europe, I change the kernel timezone to Madrid (GMT+1)
ls shows now 7pm for ext2, but 12am for hfs, so the timestamp
order has been screwed up.
My opinion is that any change which make potentially reorder timestamps
between file systems is so bad that it should be avoided at all costs.
Conclusion: you should never change the kernel timezone if you don't want
this to happen and you have a mixture of UTC and non UTC filesystems.
(Note that I did not put a network transfer in the example, if you do
this, you rapidly reach the conclusion that you must be able to always get
the timestamps back to UTC from whatever the filesystem stores).
Hmm, from what I see, HFS+ seems to use UTC filestamps. That's fine.
Regards,
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/