From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE macro Date: Thu, 15 Jan 2015 13:39:33 +0000 Message-ID: <54B7C315.4030103@linaro.org> References: <1418760534-18163-1-git-send-email-julien.grall@linaro.org> <1418760534-18163-4-git-send-email-julien.grall@linaro.org> <5491636F020000780005027B@mail.emea.novell.com> <54917D1C.3080908@linaro.org> <5491B91802000078000C40B1@mail.emea.novell.com> <5491C2EE.4080603@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YBkea-0003N4-10 for xen-devel@lists.xenproject.org; Thu, 15 Jan 2015 13:40:04 +0000 Received: by mail-wi0-f174.google.com with SMTP id h11so35192419wiw.1 for ; Thu, 15 Jan 2015 05:40:02 -0800 (PST) In-Reply-To: <5491C2EE.4080603@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , Jan Beulich Cc: keir@xen.org, ian.campbell@citrix.com, tim@xen.org, manish.jaggi@caviumnetworks.com, ian.jackson@eu.citrix.com, stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org List-Id: xen-devel@lists.xenproject.org Hi, On 17/12/14 17:52, Andrew Cooper wrote: > On 17/12/14 17:10, Jan Beulich wrote: >>>>> Julien Grall 12/17/14 1:55 PM >>> >>> On 17/12/14 10:05, Jan Beulich wrote: >>>>>> On 16.12.14 at 21:08, 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