This is a discussion on Re: New "timeout" api, to replace callout - FreeBSD ; In message , Luigi Rizzo writes: >On Sat, Dec 01, 2007 at 10:19:05PM +0000, Poul-Henning Kamp wrote: >> /* >> * A duration of time, represented in the optimal way for a given provider >> * or family of providers ...
In message <20071202045134.A7421@xorpc.icir.org>, Luigi Rizzo writes:
>On Sat, Dec 01, 2007 at 10:19:05PM +0000, Poul-Henning Kamp wrote:
>> * A duration of time, represented in the optimal way for a given provider
>> * or family of providers (ie: per cpu).
>> typedef int timeout_time;
>is this meant to be parsable by client code, or should it be
>opaque (even though of known size) ?
Opaque to clients.
It is likely to be scaled to some hardware counters clock period,
but that is internal to the provider.
>> * Flag values,
>> * can be used as return from the function or as argument to timeout_arm()
>> #define TIMEOUT_REARM (1<<0)
>any reason not to use an enum for these ?
Enums make static code checkers barf when your OR their values.
C doesn't have bitmapts, which is a strange oversight.
>> timeout_time timeout_ns_time(struct timeout_p *, unsigned nsec);
>> timeout_time timeout_us_time(struct timeout_p *, unsigned usec);
>> timeout_time timeout_ms_time(struct timeout_p *, unsigned msec);
>> timeout_time timeout_s_time(struct timeout_p *, unsigned sec);
>Two questions here:
>1. is there any need for the first argument not to be const ?
> If all the function do is a conversion, there shouldn't be any
> need to modify the timeout_p
No, it can probably be const.
I think I have also convinced myself to change this to be one
function with a scaling specified:
#define TIMEOUT_NSEC (1 << 9)
#define TIMEOUT_USEC (1 << 6)
#define TIMEOUT_MSEC (1 << 3)
#define TIMEOUT_SEC (1 << 0)
timeout_time timeout_conv_time(struct timeout_p *, unsigned val, unsigned scale) ;
>2. I fully agree that the precision level should be a user-supplied
> parameter, but wonder whether ns/us/ms/s is really the set of
> precisions one might want. I could see a need for at least the
> following requests:
> "as accurate as possible"
> "one timecounter tick accuracy, whatever the tick is"
> "one timer tick (1/HZ) accuracy, whatever the tick is"
Ticks may cease to have importance with hardware like the HPET
where we can implement deadlining instead of periodic scheduling.
It may make sense to offer ranges or tolerances, but that can be
added later if we find that we need it.
The goal here and now, in this area of the API, is only to kill HZ
as a specification unit of time.
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@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.
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"