WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

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