Re: [Xen-devel] Re: [rfc] [patch] grant_entry.flags accessors

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

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