Re: lockmgr_sleep() (was Re: ssleep() (was Re: mention msleep() in porting_drivers.txt))

[Aggelos Economopoulos <aoiko@xxxxxxxxxxxxxx>]

On Wednesday 16 January 2008, Simon 'corecode' Schubert wrote:
> Aggelos Economopoulos wrote:
> > So, about adding a lockmgr_sleep(): I think it would be useful; open-coding
> > the whole thing makes it easy to slip in hard to notice bugs. But what should
> > the prototype be? If we follow the freebsd semantics, the lock should be re-
> > acquired on return. This means that we need to do a lockstatus() (which implies
> > a spin_lock_wr()) to get information that the caller probably has available or
> 
> Why?  When we release the lock in lock_sleep, we will obtain the status 
> anyways, right?

Assuming you mean lockmgr_sleep() here, no. lockmgr(LK_RELEASE) only returns
0. OTOH nobody in the tree actually checks for that, so we could change
lockmgr to return the lock status in that case. This seems to solve the
problem nicely. Any objections to that?

[...]
> > The down side of course is having to change a couple of dozen call sites. But
> > as long as we're breaking people's patches with the name change, we might as
> > well fix the interface, assuming everyone agrees that's an improvement.
> 
> No problem.  We could keep msleep() around for some time.

Maybe for a little bit (and with a big warning to prevent people from using
it; this is a good chance to bring in __attribute__(deprecated)) in order to
avoid breakage for out of tree code, but if we add spin_sleep(), msleep()
has to go. We don't want to end up like freebsd (which has mtx_sleep() AND
msleep()), right? ;)

Aggelos