From: Geert Uytterhoeven
Date: Thu Dec 16 2004 - 07:20:42 EST
On Thu, 16 Dec 2004, Gabriel Paubert wrote:
> On Wed, Dec 15, 2004 at 06:04:03PM +0000, Alan Cox wrote:
> > On Maw, 2004-12-14 at 00:16, Eric St-Laurent wrote:
> > > On a related subject, a few months ago you posted a patch which added a
> > > nice add_timeout()/timeout_pending() API and converted many (if not
> > > most) drivers to use it.
> > >
> > > If I remember correctly it did not generate much comments and the work
> > > was not pushed into mainline.
> > >
> > > I think it's a nice cleanup, IMHO the time_(before|after)(jiffies, ...)
> > > construct is horrible.
> > >
> > > Any chance to resurrect this work ?
> > I plan to ressurect it when I have a little time but with some small
> > additions from the original work. Several people said "it should be mS
> > not HZ" and someone at OLS proposed that the API also includes an
> > accuracy guide so that systems using programmed wakeups can aggregate
> > timers when accuracy doesn't matter.
> I suspect people who want to push HZ to 10000 won't be happy with
> milliseconds since it would not give them a resolution of one jiffy.
> So the options are:
> 1) microseconds, allows up to roughly half an hour (signed)
> or an hour (unsigned).
> 2) nanoseconds, needs 64 bits, nice for 64 bit machines but
> at the risk of bloat on 32 bit ones.
> 3) timespecs, somewhat wasteful on 64 bit machines (two longs).
> I believe 1) is the best compromise.
Yep. And if the need for ns arises, add a _different_ function (e.g. *_ns()) to
wait with ns-resolution. 64 bit is probably not needed, who wants to wait for
more than a few seconds with ns-resolution?
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/