[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,

On 17/12/14 17:52, Andrew Cooper wrote:
> On 17/12/14 17:10, Jan Beulich wrote:
>>>>> Julien Grall <julien.grall@xxxxxxxxxx> 12/17/14 1:55 PM >>>
>>> On 17/12/14 10:05, Jan Beulich wrote:
>>>>>> On 16.12.14 at 21:08, <julien.grall@xxxxxxxxxx> wrote:
>>>>> +#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.
>> I realize that's the motivation, but I also view it as problematic to have 
>> two
>> different constructs doing the same thing. Defining the new one in terms of
>> the existing ones doesn't seem possible (or else I would suggest that in
>> order for the connection to be obvious). We'll see what other maintainers
>> think...
> 
> Personally, I find the semantics of ACCESS_ONCE() more intuitive than
> read/write_atomic(), and it is certainly more familiar to Linux developers.
> 
> Furthermore, ACCESS_ONCE() doesn't force an mov instruction if the
> compiler can identify a better instruction to use.
> 
> There are only a handful of user users of read/write_atomic().  It would
> not be hard to make a blanket switch, if we chose to go in that direction.

It seems the next version of Linux will start to replace ACCESS_ONCE by
READ_ONCE/WRITE_ONCE.

So I will drop this patch and declare ACCESS_ONCE in the SMMU driver. I
will keep it as long as Linux is still using ACCESS_ONCE in this driver.

Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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