Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Bret S. Lambert (bret.lambertgmail.com)
Date: Fri Aug 20 2010 - 15:22:24 CDT
On Fri, Aug 20, 2010 at 12:27:39PM -0700, Matthew Dempsky wrote:
> On Fri, Aug 20, 2010 at 11:47 AM, Bret S. Lambert
> <bret.lambertgmail.com> wrote:
> > And this one, like that one, lacks context.
> The hzto/tvtohz diff was just a const correctness fix. I didn't think
> it needed more context on its own.
> > What's the ultimate goal? Just to remove some calls to hzto?
> timeout(9) suggests avoiding using timeout_add(9) directly in favor of
> higher-level functions, and I think it's worth adding utility
> functions for common use patterns. I just noticed that a number of
> remaining timeout_add(9) calls were of the form timeout_add(...,
> >From an abstraction point of view, I don't think it makes sense for so
> much code to needlessly know about "ticks".
So...yes, it *was* just to remove calls to hzto. And you're adding
another interface for it, which just seems grotesque and excessive.
IMO, the correct way to get rid of this is to use the macros
provided in time.h which do math on timevals, and then stuff that
derived value into a timeout_add_tv.
Also realize that there were subtle issues with hz<->tv conversions
when I started converting to the timeout_add_foo functions, which
need to be resolved before we can do these conversions, as the
conversions in sys/kern/kern_clock.c do something differently,
and not doing it in that manner ends up whacking out drivers
which implicitly depend upon that behavior.
Please read those, and join me in my WTF.