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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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. 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