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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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