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

[Aggelos Economopoulos]

On Saturday 26 January 2008, Aggelos Economopoulos wrote:
> On Wednesday 16 January 2008, Aggelos Economopoulos wrote:
> > On Wednesday 16 January 2008, Matthew Dillon wrote:
> > >     lockmgr_sleep(ident, lock, slpflags, wmesg, timeo)
> > > 
> > >     lockmgr_sleep can also figure out what kind of lock is held internally
> > >     and deal with it, or it can just assume an exclusive lock.  Either way
> > >     lkflags do not have to be passed to it.
> > 
> > Assuming an exclusive lock is not intuitive IMO and differs from the FreeBSD
> > semantics (even though it matches our msleep()/spin_sleep()). What do you
> > think of the lockmgr change suggested in another mail in this thread?
> > 
> > > 
> > > :If we're going to rename msleep() to spin_sleep() anyway, I suggest changing
> > > :the prototype to
> > > :
> > > :spin_sleep(void *ident, int flags, const char *wmesg, int timo,
> > > :	struct spinlock *spin)
> > > 
> > >     We want all the *sleep() procedures to use a similar prototype,
> > >     and in this case being compatible with our own history as well
> > >     as FreeBSD's will reduce confusion to a minimum.  That means putting
> > >     the lock as the second argument.
> > > 
> > >     spin_sleep(ident, spin, slpflags, wmesg, timeo)
> > 
> > Nobody can disagree with the "compatible" part, but for a whatever_sleep()
> > that does a "drop, tsleep() and reacquire whatever lock" it seems more
> > natural to require the tsleep() args followed by the whatever args. It may
> > be unlikely, but imagine having to add another flag. Would you put it after
> > "spin" seperating the tsleep() args further?
> > 
> > Also, I don't think FreeBSD compatibility is an issue, unless the two choices
> > are otherwise on par.
> 
> So what's the verdict? Veto still on? Need to know in order to submit a patch :)

Yet another ping.

Aggelos