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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 11/12/15 07:53, Jan Beulich wrote:
>>>> 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.

This is all true, but it is better to have it consistent everywhere
rather than to change just half of it.

~Andrew

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