Re: *_trylock return on success?

[george anzinger <george@mvista.com>]

So what is a coder to do.  We need to define the pi_mutex_trylock().  If
I understand this thread, it should return 0 on success.  Is this
correct?

George


On Saturday 25 November 2000 22:05, Roger Larsson wrote: 
> On Saturday 25 November 2000 20:22, Philipp Rumpf wrote: 
> > On Sat, Nov 25, 2000 at 08:03:49PM +0100, Roger Larsson wrote: 
> > > > _trylock functions return 0 for success. 
> > > 
> > > Not spin_trylock 
> > 
> > Argh, I missed the (recent ?) change to make x86 spinlocks use 1 to mean 
> > unlocked. You're correct, and obviously this should be fixed. 

Have looked more into this now... 
tasklet_trylock is also wrong (but there are only four of them) 
Is this 2.4 only, or where there spin locks earlier too? 

My suggestion now is a few steps: 
1) to release a kernel version that has corrected _trylocks; 
    spin2_trylock and tasklet2_trylock. 
    [with corresponding updates in as many places as possible: 
      s/!spin_trylock/spin2_trylock/g 
      s/spin_trylock/!spin2_trylock/g 
      . . .] 
    (ready for spin trylock, not done for tasklet yet..., attached, 
     hope it got included OK - not fully used to kmail) 

2) This will in house only drives or compilations that in some 
    strange way uses this calls... 

3a) (DANGEROUS) global rename spin2_trylock to spin_trylock 
     [no logic change this time - only name] 
3b) (dangerous) add compatibility interface 
     #define spin_trylock(L) (!spin2_trylock(L)) 
     Probably not necessary since it can not be linked against. 
     Binary modules will contain their own compatibility code :-) 
     Probably preferred by those who maintain drivers for several 
     releases; 2.2, 2.4, ... 
3c) do not do anything more... 

Alternative: 
1b) do nothing at all - suffer later 

/RogerL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/