Messages in this thread |  | | Date | Mon, 04 Dec 2000 11:46:42 -0800 | From | george anzinger <> | Subject | Re: *_trylock return on success? |
| |
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/
|  |