Re: API explosion (Re: [RFC/RFT] calloutng)

--------
In message <50D192E8.3020704_at_FreeBSD.org>, Alexander Motin writes:

>Linux uses 32.32 format in their eventtimers code.

(And that is no accident, I know who they got the number from :-)

>But if at some point we want to be able to 
>handle absolute wall time, [...]

Then you have other problems, including but not limited to clock
being stepped, leap-seconds, suspend/resume and frequency stability.

If you want to support callouts of the type ("At 14:00 UTC tomorrow")
(disregarding the time-zone issue), you need to catch all significant
changes to our UTC estimate and recalibrate your callout based on
that.

It is not obvious that we have applications for such an API that
warrant the complexity.

Either way, such a facility should be layered on top of the callout
facility, which should always run in "elapsed time"[1] with no attention
paid to what NTPD might do to the UTC estimate.

So summary: 32.32 is the right format.

Poul-Henning

[1] Notice that "elapsed time" needs a firm definition with respect
to suspend/resume, and that this decision has big implications
for the API use and code duplication.

I think it prudent to specify a flag to callouts, to tell what
should happen on suspend/resume, something like:

	SR_CANCEL	/* Cancel the callout on S/R */
	/* no flag*	/* Toll this callout only when system is running */
	SR_IGNORE	/* Toll suspended time from callout */

If you get this right, callouts from device drivers will just "DTRT",
if you get it wrong, all device drivers will need boilerplate code
to handle S/R

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.