Bear with me Dave, I'll repeat myself a bit, for the benefit of lkml.
Andi Kleen wrote:
Yeah quite a few. I suspect most MIPS also would have a problem in this
area.
cmpxchg can be done with LL/SC can't it? Any MIPS should have that.
Right.
On PARISC, I don't see where they are emulating compare and swap
as indicated. They are doing the funny hashed spinlocks for the
atomic_t operations and bitops, but that is entirely different.
Yep, same as SPARC (at least, SPARC's 32-bit atomic_t).
cmpxchg() has to operate in an environment where, unlike the atomic_t
and bitops, you cannot control the accessors to the object at all.
The DRM is the only place in the kernel that requires cmpxchg()
and you can thus make a list of what platform can provide cmpxchg()
by which ones support DRM and thus provide the cmpxchg() macro already
in asm/system.h
We really can't require support for this primitive kernel wide, it's
simply not possible on a couple chips.
Not a generic cmpxchg, no. However, I _believe_ that those
architectures that are missing something like ll/sc or real
atomic cmpxchg should still be able to implement an
"atomic_cmpxchg" on their atomic type.
Sorry if I wasn't at all clear initially. What I'd be interested
in is an architecture that doesn't support ll/sc or real cmpxchg
*and* does not implement atomic_t operations with locks.
Thanks,
Nick
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |