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().
That said, I can see wall-clock time waits in third-party modules (think
of things like OpenAFS). But then, one can always turn those into
reltimedwaits [except in real-time contexts?].
Nico
--
