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

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Andrew Cooper,

On 17/12/2014 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.
Do you mean replacing read/write_atomic() by

#define read_atomic(p) ACCESS_ONCE(p)
#define write_atomic(p, x) (ACCESS_ONCE(p) = x)

Regards,

--
Julien Grall

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