"John F. Woods" <jfw@jfwhome.funhouse.com> writes:
> > I've been thinking about a bunch of ways to fix this nit, but most of
> > them involve spinning for up to one second, which isn't really a good
> > idea. I was therefore wondering if people on tech-kern had any
> > opinions on the "correct" method.
> 
> Someone to whom near-microsecond accuracy is truly important might well
> not begrudge a whole extra second in the boot process -- unless there is
> some kind of device-initialization issue that could get fouled up.

Spinning is fine during boot. resettodr(), however, occurs all the
time -- often at times that are likely very inconvenient for the
hardware to lock up for a second -- and unless both are fixed it would
not help.

> A cheap way to fix it to HZ resolution would be to set the time lazily;
> instead of initializing the in-memory time inline in the boot code to the
> rounded second value, simply ensure that the clock interrupt code will
> initialize the time the next interrupt which sees a different second value.

I don't know that this is necessarily practical -- hardclock is a
pretty expensive place to do this, especially given how gross the
device access machinery is.

> You could also combine the two ideas by setting the time very lazily:  the
> clock interrupt code could be primed to watch for the second value changing,
> and once it sees that transition, start a countdown:  the HZ-1'th next
> clock interrupt will then spinwait for up to 1/HZ seconds waiting for the
> second value to change, and set the time then.  (Possibly to avoid a race
> you should trigger on the HZ-2'th next interrupt and be prepared to spinwait
> for 2/HZ seconds -- potentially (usually) missing one clock interrupt.
> 
> A third alternative is to just ignore the problem:  if someone truly wants
> sub-second time accuracy from the moment their system is booted, perhaps
> they should be thinking dedicated hardware, not hoping there's enough layers
> of software bandages over their 300ppm PC clock circuit...