Re: [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE macro

[Julien Grall <julien.grall@linaro.org>]

Hi Jan,

On 17/12/14 10:05, Jan Beulich wrote:
>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>> --- a/xen/include/xen/compiler.h
>> +++ b/xen/include/xen/compiler.h
>> @@ -90,4 +90,18 @@
>>      __asm__ ("" : "=r"(__ptr) : "0"(ptr));      \
>>      (typeof(ptr)) (__ptr + (off)); })
>>  
>> +/*
>> + * Prevent the compiler from merging or refetching accesses.  The compiler
>> + * is also forbidden from reordering successive instances of ACCESS_ONCE(),
>> + * but only when the compiler is aware of some particular ordering.  One way
>> + * to make the compiler aware of ordering is to put the two invocations of
>> + * ACCESS_ONCE() in different C statements.
>> + *
>> + * This macro does absolutely -nothing- to prevent the CPU from reordering,
>> + * merging, or refetching absolutely anything at any time.  Its main intended
>> + * use is to mediate communication between process-level code and irq/NMI
>> + * handlers, all running on the same CPU.
>> + */
>> +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
> 
> Any reason not to simply use {read,write}_atomic() instead, which we
> already have?

To avoid modifying Linux drivers when it's not necessary and doesn't harm.

Regards,

-- 
Julien Grall