Re: [Xen-devel] [PATCH 2/2] x86/HVM: fix preemption handling in do_hvm_op()

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 03/26/2014 03:44 PM, Jan Beulich wrote:
> > > > On 26.03.14 at 15:42, <George.Dunlap@xxxxxxxxxxxxx> 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

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