[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] public/sysctl: Clarifications to XEN_SYSCTL_PHYSCAP_hvm_directio



>>> On 10.12.15 at 21:07, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 01/12/15 13:35, Jan Beulich wrote:
>>>>> On 01.12.15 at 12:37, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> --- a/xen/include/public/sysctl.h
>>> +++ b/xen/include/public/sysctl.h
>>> @@ -89,7 +89,14 @@ DEFINE_XEN_GUEST_HANDLE(xen_sysctl_tbuf_op_t);
>>>   /* (x86) The platform supports HVM guests. */
>>>  #define _XEN_SYSCTL_PHYSCAP_hvm          0
>>>  #define XEN_SYSCTL_PHYSCAP_hvm           (1u<<_XEN_SYSCTL_PHYSCAP_hvm)
>>> - /* (x86) The platform supports HVM-guest direct access to I/O devices. */
>>> + /*
>>> +  * (x86) The platform supports guest direct access to I/O devices.
>>> +  *
>>> +  * Note that this parameter has been misnamed since its introduction, and 
>>> is
>>> +  * now too baked into APIs and ABIs to change.  Despite the "hvm" in its
>> What do you mean with "too baked into ..."? This is sysctl, which can
>> be changed, and I found just two uses (one in the hypervisor, the
>> other in libxl), so changing the use sites wouldn't seem all that
>> problematic (in the worst case we could also keep to current name
>> behind a __XEN_INTERFACE_VERSION__ conditional).
> 
> It is libxl which is the problem.  Given its stable API,
> libxl_physinfo.cap_hvm_directio can't be changed.

But that's only derived from the sysctl interface, i.e. changing the
name in the public headers won't - unless I'm overlooking something -
have any effect on the libxl interface. It's the libxl implementation
which would then need to explain (for itself) that the name doesn't
reflect the function.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.