Perry E. Metzger wrote:
> Garrett D'Amore <garrett_damore@tadpole.com> writes:
>   
>> All that said, I don't mind waiting up to a second to get rid of the drift.
>>     
>
> Neither do I, so we can quit discussing the side issues. :)
>
> So lets just code. :)
>
> In theory, ports might have battery clocks with higher precision than
> one second, but I haven't encountered one, so on the KISS principle we
> can ignore that issue until such a clock appears. (If one does appear,
> a simple flag saying "don't spin" is probably enough because we'll get
> decent microsecond or nanosecond data out from it without spinning.)
>
> So, repeating the earlier proposal, we then just have some simple code
> that spins in the inittodr case for an appropriate period, and some
> simple code that sleeps-then-sets for the resettodr case. We're then
> "good enough" for now, and if people want to do harder stuff later
> they can.
>
> So, getting quite practical for a moment, the question is, do we want
> to do the inittodr spin in todr_gettime or in the MD code? I favor
> doing it in MI code if at all possible, in which case todr_gettime is
> probably the place.
>   

Actually, my opinion is that todr_gettime() should do this only for the
drivers that use todr_gettime_ymdhms.  The other drivers can pass a
usec, and might not need to delay.  Besides, this is really only useful
for PCs, which use the newer clock_ymdhms versions.  (Other ports
generally don't care about a 1 second drift, because they aren't being
suspended/restarted all day.  Of course there are sparc laptops, but
they also use the clock_ymdhms versions, and so will automatically
benefit as well.)

> On the todr_settime side, it should be pretty easy to set the sleep
> until the next tick happens right in todr_settime.
>   

Yes, but again, you don't want to do that if the rtc actually has
subsecond precision.  Several do.

> BTW, as an aside, why is the /* simple sanity checks */ still in
> todr_gettime rather than clock_ymdhms_to_secs? (Also, for that check,
> keep in mind that particularly politically correct clocks could have
> dt_sec hit 61 during leap seconds.)
>   

I copied that check from elsewhere.  I haven't touched clock_subr.c  I'm
considering moving clock_subr.c into kern_todr.c, and when I do, I'll
move (and fix) the check.

    -- Garrett
> Perry
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191