From: Ethan Benson <erbenson@alaska•net>
To: linuxppc-dev@lists•linuxppc.org
Subject: Re: DST flag in NVRAM revisited (was: Re: NVRAM stuck in DST?)
Date: Thu, 28 Mar 2002 04:04:42 -0900 [thread overview]
Message-ID: <20020328040442.V26309@plato.local.lan> (raw)
In-Reply-To: <E16qY53-0000Iw-00@piglet.grunz.lu>; from mlan@cpu.lu on Thu, Mar 28, 2002 at 12:28:27PM +0100
On Thu, Mar 28, 2002 at 12:28:27PM +0100, Michel Lanners wrote:
>
> In arch/ppc/kernel/time.c, kernel time is set from the RTC, implicitly
> taking RTC for GMT time. Under MacOS, however, it's localtime. On pmac,
> we use the GMT offset MacOS stores in nvram to correct this, and correct
> kernel time to real GMT. We also set kernel timezone info, but it's use
> is discouraged (have a look at man settimeofday).
this is broken. the kernel should just use the time stored in nvram
and ignore the crap macos is keeping there regarding time zones.
the solution to the `windows controls the hardware clock' problem was
made many years ago, hwclock can be told whether the RTC is in
localtime or GMT, just about every distro asks you this on install (at
least on x86 debian does on powerpc too).
we should just deal with the RTC exactly how its delt with on x86, if
you have windows (or in our case MacOS) you tell hwclock the RTC is in
localtime and let it deal with it, if you don't have MacOS/windows you
tell it you have the RTC in GMT like its supposed to be and all is well.
> Now, when this offset is wrong (like when DST switched and you didn't
> boot MacOS since), your intial kernel time will be wrong. However, the
which demonstrates exactly why this crap in the kernel trying to be
like macos is just plain wrong and broken.
> The question, of course, is whether Linux should maintain this GMT
> offset in nvram, since it uses it's information. If so, then who should
> maintain it where?
no it should not. the kernel should NOT know or care what the
timezone is, that belongs in userspace not kernel space. period.
the feilds macos sets should be ignored entirely by linux, not read,
not written.
> My proposition would be to correct this everytime that the RTC is
> updated (since the GMT offset belongs logicaly to the RTC function
> block). Debian does this on every system shutdown.
please don't forget systems that don't have legacy MacOS, these
systems will keep the RTC in GMT like its supposed to be.
> Obviously, the easiest thing to do is do nothing and entirely rely on
> the bootup scripts to set the correct time.
this is of course the correct solution, this problem was met and
solved YEARS ago on x86 its stupid that powerpc is fooling around with
it when there is already a well established and working solution.
> Comments anyone?
see above, in short this `lets pretend we are MacOS!!' crap in the
kernel should be *REMOVED* the kernel should not know or care about
timezones or DST, it should just read the RTC and ignore these macos
fields. the standard bootup scripts running hwclock will pass --utc
or --localtime depending on how the user configured it and all will be
fine, just like on x86 for dealing with windows.
--
Ethan Benson
http://www.alaska.net/~erbenson/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-03-28 13:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-07 7:59 NVRAM stuck in DST? Michel Lanners
2001-12-07 21:38 ` Benjamin Herrenschmidt
2001-12-07 21:39 ` Benjamin Herrenschmidt
2002-03-28 11:28 ` DST flag in NVRAM revisited (was: Re: NVRAM stuck in DST?) Michel Lanners
2002-03-28 13:04 ` Ethan Benson [this message]
2002-03-28 16:19 ` Geert Uytterhoeven
2002-03-28 23:31 ` Ethan Benson
2002-03-29 0:47 ` bug: kernel timer added twice at e3259abc Kevin B. Hendricks
2002-03-28 17:18 ` DST flag in NVRAM revisited (was: Re: NVRAM stuck in DST?) benh
2002-03-28 23:28 ` Ethan Benson
2001-12-07 22:09 ` NVRAM stuck in DST? Greg Noel
2001-12-08 11:24 ` Gabriel Paubert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020328040442.V26309@plato.local.lan \
--to=erbenson@alaska$(echo .)net \
--cc=linuxppc-dev@lists$(echo .)linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox