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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-03-27 at 08:05 +0000, Jan Beulich wrote:
> >>> On 26.03.14 at 18:06, <george.dunlap@xxxxxxxxxxxxx> wrote:
> > 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. :-)
> 
> But see - the public header doesn't have any such comments right
> now, and hence I'm implying it to state that the structures don't
> change except for fields designated for output.
> 
> > "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.
> 
> And again - you don't mention this aspect at all - consistency is quite
> significant an aspect. And the interface stability requirements at the
> libxc layer are completely independent of the ones of the hypercalls.
> Back when I joined the Xen project, it was already the case that tools-
> only interfaces were allowed to change at any time, and to my
> knowledge this didn't change.

Yes, to be clear I was only talking about the libxc A[BP]I.

I think for the purposes of supporting external device models and such
we would only need to declare a stable library wrapper interface, not
change any of the rules regarding the underlying hypercalls (i.e.
sysctl, domctl remain non-stable interfaces). If the hypercalls change
*and* we have declared a stable library interface over them then the
library would have to do impedance matching.

That's part of the reason I would insist on an enumeration and audit of
the library interfaces which we were to declare stable for the use of
qemu etc. As with the libxl stable API declaration we would want to make
sure that the interface was supportable as a frozen API going forward
before committing to it long term. I very much doubt that is the case of
many of the libxc interfaces right now.

Ian.

>  Hence if we fix the hypercalls here and
> libxc would have to retain its current interface, we'd need to adjust
> libxc accordingly (as said in the original submission, some change to
> the library is going to be at least desirable anyway).
> 
> Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



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