From mboxrd@z Thu Jan  1 00:00:00 1970
From: Julien Grall <julien.grall@citrix.com>
Subject: Re: [PATCH 4/4] xen/public: arm: rework the macro
	set_xen_guest_handle_raw
Date: Wed, 4 Nov 2015 16:59:02 +0000
Message-ID: <563A3956.8030308@citrix.com>
References: <1446228813-2593-1-git-send-email-julien.grall@citrix.com>
	<1446228813-2593-5-git-send-email-julien.grall@citrix.com>
	<alpine.DEB.2.02.1511031415430.3438@kaball.uk.xensource.com>
	<5638D1E4.4010208@citrix.com>
	<22074.12469.923941.837807@mariner.uk.xensource.com>
	<563A42E202000078000B1DC3@prv-mh.provo.novell.com>
	<22074.14145.634793.537784@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=743614dca=julien.grall@citrix.com>)
	id 1Zu1Qr-0001Ux-A5
	for xen-devel@lists.xenproject.org; Wed, 04 Nov 2015 17:01:09 +0000
In-Reply-To: <22074.14145.634793.537784@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>, Jan Beulich <JBeulich@suse.com>
Cc: Tim Deegan <tim@xen.org>, xen-devel@lists.xenproject.org, Keir Fraser <keir@xen.org>, ian.campbell@citrix.com, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

On 04/11/15 16:50, Ian Jackson wrote:
> Jan Beulich writes ("Re: [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw"):
>> All quite interesting, but pretty moot with there not being any
>> get_xen_guest_handle() anymore.
> 
> If we don't provide a get_xen_guest_handle, a kernel developer will be
> sorely tempted to make one.
> 
> If they do and they write it in the obvious way, then the compiler
> could `deduce' that the top part of the uint64_t store was dead, and
> eliminate it.

The developers could also decide to rewrite the
set_xen_raw_guest_handle/get_xen_guest_handle in an obvious way because
they think ours it's too complicate... See the Linux version.

TBH, we can't protect ourself for a developer writing it own macro and
don't think about the big picture. The comment in the header pretty much
explain the constraint. If it doesn't read, well it's not our business.

Regards,

-- 
Julien Grall