rtc again...

Takashi Oe toe at unlserve.unl.edu
Sun Aug 6 00:44:50 EST 2000


On Sat, 5 Aug 2000, Benjamin Herrenschmidt wrote:

> >
> >As Geert has pointed out, hwclock can give UTC or local time to /dev/rtc,
> >why don't we just let userland deal with this local time issue.  What I
> >mean is for pmac_set_rtc_time(), let's change:
>
> That would give us back what we had at the beginning. This way, userland
> is solely responsible for this setup, which means it will be wrong on 50%
> of user machines (but that's user fault isn't it ?) and which means the
> kernel will boot with a wrong time, at least until the userland init
> script takes over.

Hmm, nothing has been changed with pmac_get_rtc_time().  So, if it is
broken now, it was broken before....  Seriously, pmac_get_rtc_time() is
the one responsible for giving you the correct time at boot time, isn't
it?

Does xtime need to be in UTC?  If so, is it feasible to let
ppc_md.time_init() give an offset in seconds from UTC to the time given by
RTC?

  void __init time_init(void)
  {
	unsigned long flags;
+ 	int offset = 0;
  	if (ppc_md.time_init != NULL)
  	{
  		offset = ppc_md.time_init();
  	}
	...
  	write_lock_irqsave(&xtime_lock, flags);
- 	xtime.tv_sec = ppc_md.get_rtc_time();
+ 	xtime.tv_sec = ppc_md.get_rtc_time() + offset;
  	write_unlock_irqrestore(&xtime_lock, flags);
	...

Oh, and change time_sleep_notify() in pmac_time.c accordingly.

> I don't see why it's such a mess to simply read the default values from
> xpram so we are consistent with MacOS. But everything in Linux is a mess
> anyway...

Maybe because pmac's RTC is in local time for one?


Takashi Oe


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





More information about the Linuxppc-dev mailing list