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:
> > 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?
> 
> lockmgr_sleep (or lock_sleep?) knows the internals of a lockmgr lock and 
> thus can optimize the access.

Yes, but do you really want to split the code in

lockmgr()
	case LK_RELEASE:

to a seperate function and call it from lock_sleep() (btw I agree that
lock_sleep() is a better name)? Changing lockmgr() just needs a few extra
lines.

[...]
> You mean msleep() has to go after a deprecation period, right?  (period 
> being one release cycle = 6 months)

Right.

Aggelos