DragonFly submit List (threaded) for 2008-05
Re: lockmgr_sleep() (was Re: ssleep() (was Re: mention msleep() in porting_drivers.txt))
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.