| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ppc-devel
Re: [Xen-devel] Re: [rfc] [patch] grant_entry.flags accessors
On 27 Jun 2006, at 18:45, Jimi Xenidis wrote:
Hmm, the interesting part is that as far as bit-ops go in Linux x86
converged to longs rather then ppc converging to some the arbitrary
bit method:
see:
include/asm-i386/bitops.h clear_bit 71 static inline void
clear_bit(int nr, volatile unsigned long * addr)
I've been told this was to solve a performance issue, but I am no
expert.
Well there would be a performance impact for other architectures, no
doubt. x86/64 never moved to longs for bitops.
, but anyway: How about add a ARCH_SUPPORTS_UNALIGNED_CMPXCHG and
move special gnttab_cmpxchg() definition to gnttab.c, compilation
dependent on that?
cmpxchg will take 1,2,4 byte, and pc will take to, however we need to
abstract these anyway because the values are castes to a u32 and or'd
in an little endian way.
Or rename the gnttab_cmpxchg to synch_cmpxchg_unaligned so at least
the name is a bit more generic. It could then be used in other
contexts.
The _main_ issue is not really alignof(p), beacuse the Xen code is
careful about that, but sizeof(*p)which we need to calculate the bit
position. Thats where this interface can get a little loosy for me.
Then pick a different name. :-) *_subword()? I won't put a
gnttab_foo() in synch_bitops.h.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home