periodically save current time to time-of-day hardware

[Dag-Erling Smørgrav]

Peter Jeremy <peterjeremy at acm.org> writes:
> Traditionally, the (PC) RTC is on the ISA bus (though it's possible it
> might use I2C on other architectures or LPC on current PCs).

AFAIK, it's usually on I2C on non-i386 platforms.  I2C RTC chips are
dirt cheap and easy to integrate, especially if you already have I2C
temperature sensors and whatnot.

> > Actually, it might be a good idea to call resettodr() any time the
> > clock is stepped.
> This should occur now via kern_time.c::settime().

OK.

> Given that:
> - resettodr() needs to be serialised;
> - resettodr() may take a significant amount of time; and
> - resettodr() should ideally be synchronised to the second boundary;
> maybe creating a kthread to manage the RTC updating is reasonable.

If "synchronised to the second boundary" means what I think it means
(set the RTC at the exact top-of-the-second), don't go out of your way
to implement that.  You don't get that kind of accuracy back when you
read it anyway - unless it's a calibrated RTC (I've written a Linux
driver for one, hence my familiarity with eleven-minute-mode etc.)

> A new kthread which sleeps on channel "update_rtc".  When woken, it
> checks to see if it's within (say) 50msec of a second boundary and so,
> it does a trylock on the (new) RTC mutex.  If it grabs the mutex then
> it performs the update.  If it was too far from the second boundary or
> it fails to grab the mutex then it sleeps until the next second
> boundary and tries again.
>
> The existing resettodr() would then turn into a wakeup(update_rtc).

Sounds good to me, but if only that thread has access to the RTC, why
bother with a mutex?

DES
-- 
Dag-Erling Smørgrav - des at des.no