Nicolas Williams wrote:
> On Tue, Sep 01, 2009 at 03:35:19PM -0700, Rafael Vanoni wrote:
>> Garrett D'Amore wrote:
>>> Rafael Vanoni wrote:
>>>> There are still many consumers of cv_timedwait who need to pass in an
>>>> absolute time. cv_wait serves a similar purpose but without the timed
>>>> component, so it's functionality doesn't overlap with cv_reltimedwait().
>>> Really? In device drivers? Because darn near every time I've used
>>> cv_timedwait (and I've used it a *lot* over my career), what I really
>>> wanted was a relative time (usually for a timeout.) I can't think of
>>> any reason in normal kernel code why you'd want an *absolute* time.
>>> (Apart from the kernel proper, where I can see absolute times being
>>> useful for wall clock kinds of things.)
>> Yes, both in kernel and drivers (iwh and iwk2, for instance). I can come
>> up with a list if you're interested.
>
> Er, iwh and iwk2 do this:
>
> clk = ddi_get_lbolt() + drv_usectohz(1000000);
>
> /* wait loading run_text until completed or timeout */
> while (!(sc->sc_flags & IWH_F_PUT_SEG)) {
> if (cv_timedwait(&sc->sc_put_seg_cv, &sc->sc_glock, clk) < 0)
> {
> break;
> }
> }
>
> Looks like a candidate for cv_reltimedwait().
It seemed that way to me before the first code reviewer (Madhavan)
pointed out that with cv_reltimedwait() the timer would be reloaded with
the same delta at each iteration - where it had originally specified an
absolute time limit.
Thanks,
Rafael
