[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE macro
Hi Jan, On 17/12/14 10:05, Jan Beulich wrote: >>>> On 16.12.14 at 21:08, <julien.grall@xxxxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |