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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.12.15 at 11:20, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

I disagree (we should eliminate as much confusion as possible), but
I'm fine to be overruled by other REST maintainers.

Jan


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