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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
