[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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:
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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.