| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [rfc] [patch] grant_entry.flags accessors
On Jun 27, 2006, at 12:55 PM, Keir Fraser wrote:
I shouldn't imagine they'd mind the interface being made more
permissive, with no performance loss for the common case and no
extra API complexity
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.
, 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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home