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.lamb...@gmail.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(..., > hzto(&tv)). > > >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.
