> I'm again probably missing something, but what is "clumsy" about defining a> structure like the following to ensure proper alignment of the target> pointer (instead of adding a runtime test) ?>> struct cmpxchg_double {> #if __BYTE_ORDER == __LITTLE_ENDIAN> unsigned long low, high;> #else> unsigned long high, low;> #endif> } __attribute__((packed, aligned(2 * sizeof(unsigned long))));>> (note: packed here along with "aligned" does _not_ generate ugly bytewise> read/write memory ops like "packed" alone. The use of "packed" is to let the> compiler down-align the structure to the value requested, instead of uselessly> aligning it on 32-byte if it chooses to.)>> The prototype could then look like:>> bool __this_cpu_generic_cmpxchg_double(pcp, oval_low, oval_high, nval_low, nval_high);>> With:> struct cmpxchg_double *pcp

That does not conform to the parameter conventions in other this_cpu_ops.The first parameter is a variable because the notion of a pointer isproblematic given that percpu operations use a segment prefix to relocatepointers. You would be implicitly passing a 128 bit argument although thecompiler may not need to generate code for that.

> I think Christoph's point is that he wants to alias this with a pointer. Well,> this can be done cleanly with:>> union {> struct cmpxchg_double casdbl;> struct {> void *ptr;> unsigned long cpuid_tid;> } t;> }

There is no need for aliases with the existing implementation.

How will the macro check the parameters now?

> Thoughts ?

Could you actually try to write a patch instead running through pointsthat we have discussed earlier?