set_rtc_time() cleanup / normalization

[Eugene Surovegin]

At 01:32 AM 5/14/2003, Benjamin Herrenschmidt wrote:

> >
> > 2) set_rtc_time() implementation for concrete RTC device *maybe* slow or
> > just cannot
> >     be called from the interrupt context.
> >     Why just don't fix actual RTC code in each case ?
> >     It may be useful to provide some *generic* facility for such cases.
>
>It may just not be fixable cleanly. If you RTC is on a bus which requires
>some semaphoring for access (i2c does on pmac, though so far, the RTC isn't
>on i2c on these, I admit), or which is just so slow that you really do NOT
>want to block the machine in an interrupt that long ?

Well, fix was already suggested. Just use some kernel thread to actually
update RTC.

>Actually, the later is the most nasty. Also, since set_rtc_time() is used for
>both interrupt call and non-interrupt call, it cannot make assumptions about
>beeing able to schedule or not, thus causing the same latency problem when
>called via /dev/rtc, possibly a good DOS attack tool, but more simply, it
>just suck that way...

Well, maybe we need to functions, one that can be called from interrupt
context,
the other - usual one. Or we can test in_interrupt() in set_rtc_time and
act accordingly (although solution with two functions seems more clean).

Eugene.


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