Date: Sun, 02 Dec 2007 13:32:37 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Luigi Rizzo <rizzo@icir.org> Cc: arch@freebsd.org Subject: Re: New "timeout" api, to replace callout Message-ID: <18791.1196602357@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 02 Dec 2007 04:51:35 PST." <20071202045134.A7421@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18791.1196602357>