From mboxrd@z Thu Jan  1 00:00:00 1970
From: George Dunlap <george.dunlap@eu.citrix.com>
Subject: Re: [PATCH 2/2] x86/HVM: fix preemption handling in
	do_hvm_op()
Date: Wed, 26 Mar 2014 17:06:38 +0000
Message-ID: <5333091E.1080803@eu.citrix.com>
References: <5331B4270200007800001DFA@nat28.tlf.novell.com>
	<5331B6FB0200007800001E1D@nat28.tlf.novell.com>
	<CAFLBxZan=5-AY3PCt3mSKwbTxLvKWcXt5+AWkRn_KCG5G0VjhQ@mail.gmail.com>
	<533303D00200007800002863@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1WSrI0-0005D8-E1
	for xen-devel@lists.xenproject.org; Wed, 26 Mar 2014 17:06:56 +0000
In-Reply-To: <533303D00200007800002863@nat28.tlf.novell.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: Jan Beulich <JBeulich@suse.com>
Cc: Anthony PERARD <anthony.perard@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, Keir Fraser <keir@xen.org>, Stefano Stabellini <stefano.stabellini@citrix.com>, xen-devel <xen-devel@lists.xenproject.org>
List-Id: xen-devel@lists.xenproject.org

On 03/26/2014 03:44 PM, Jan Beulich wrote:
>>>> On 26.03.14 at 15:42, <George.Dunlap@eu.citrix.com> wrote:
>> Is there a real problem with "altering [interface structures] in a way
>> the caller may not expect"?  Can't we just document that Xen may
>> change some of the structures?
> The two main problems here, just like with the memory op we had to
> change before 4.4, are
> - we can't and shouldn't assume that qemu is the only consumer, and
>    hence surprises to the caller must be avoided
> - no interface anywhere in the tree should set bad precedents, or
>    else keeping people from doing the same wrong thing elsewhere is
>    much harder to achieve (i.e. just like in so many other places
>    recently, I'm advocating for consistency throughout the source
>    base here)

"Surprises to the caller" can be avoided by adding comments in the 
public header.  The hypercall can't be used without someone looking at 
the structure definition. :-)

"Setting a bad precedent" is a reasonable argument *if* we're not 
constrained by ABI / API compatibility.  I agree with IanC, that libxc 
should be an internal-only, unstable interface; and that we should 
probably come up with some more reasonable way to support "external" 
APIs like this for device models.

  -George