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

[Poul-Henning Kamp]

--------
In message <20121222225025.GA46583 at stack.nl>, Jilles Tjoelker writes:

>> 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.
>
>POSIX specifies functions that assume such a facility exists, although
>applications may not care much if we implement them incorrectly.

It should still be implemented op top of callouts, not as part of:
it is an entirely different thing to try to do right.

>> 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
>
>Userland could get access to this via CLOCK_REALTIME vs CLOCK_MONOTONIC
>vs CLOCK_UPTIME.

I have _no_ idea what you are trying to say here...

-- 
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.