Re: set_rtc_time() cleanup / normalization

At 10:58 PM 5/13/2003, Dan Malek wrote:

Eugene Surovegin wrote:

quoted

Why PPC arch should be different in this respect from other archs (like
i386, alpha, mips, mips64, sparc...)?

PPC is different only that it follows the i386 model.  IIRC, the others
have some selectable (or removed) feature for keeping the rtc updated.
When you have an inflexible and essentially memory mapped device (like
on i386) it makes sense to not have any options.  With embedded systems,
you have a variety of options that don't always fit this model.

Exactly, I use this feature on our systems, somebody doesn't use it at all.

So far, the only *real* issue I've seen here is that some RTC drivers weren't
written correctly.

When I wrote RTC driver for out hw, simple grep through the code revealed
the fact, that ppc_md.set_rtc_time was called from interrupt context.
It's not a rocket science.

So all this surprise about kernel setting RTC is a little strange for me.
And yes, kernel *will* crash if you write a buggy driver.

I don't understand why instead of fixing those drivers we should remove
this feature altogether.

quoted

Frankly, I expect my tipb to behave exactly the same as my Intel box.

Why would you want such a superior architecture like tipb to work
so poorly? :-)

Well, I just use tipb as an example of box running PPC kernel which has the
same setup as my Intel box running the same kernel version.

The tipb isn't the issue, but if you look carefully
at all of these systems they all use user space programs to ensure
the rtc and system date/time/timezone are set properly.

quoted

Maybe we should raise this issue on lkml?

They won't care.  One, it's not x86, two, it's architecture specific.

Well, it's not entirely arch specific.
This behavior is *documented* (see hwclock(8) man pages for example).

Eugene.


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