Re: [Xen-devel] [PATCH 2/2] xen: Drop DOMCTL_getmemlist and xc_get_pfn_list()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.01.18 at 13:52, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 22/01/18 12:41, Jan Beulich wrote:
>>>>> On 19.01.18 at 20:19, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> --- a/xen/include/public/domctl.h
>>> +++ b/xen/include/public/domctl.h
>>> @@ -1117,7 +1117,7 @@ struct xen_domctl {
>>>  #define XEN_DOMCTL_pausedomain                    3
>>>  #define XEN_DOMCTL_unpausedomain                  4
>>>  #define XEN_DOMCTL_getdomaininfo                  5
>>> -#define XEN_DOMCTL_getmemlist                     6
>>> +/* #define XEN_DOMCTL_getmemlist                  6 Obsolete */
>>>  /* #define XEN_DOMCTL_getpageframeinfo            7 Obsolete - use 
> getpageframeinfo3 */
>>>  /* #define XEN_DOMCTL_getpageframeinfo2           8 Obsolete - use 
> getpageframeinfo3 */
>>>  #define XEN_DOMCTL_setvcpuaffinity                9
>> Just like mentioned upon someone else's recent submission to
>> remove a domctl sub-op: You want to bump the interface version
>> (remember that the bump done for the shim doesn't count as long
>> as there is a possible plan to make that other recent commit part
>> of a 4.10.x stable release).
> 
> There has already been a version bump for 4.11.

I know, hence the longer explanation, which I had given also
when the shim series was first posted: If that domctl change is
to be backported to 4.10, interface version 0xf will be burnt
for _just that change_. That other bump is sufficient only when
there is no plan whatsoever to backport the earlier change.

>> Plus I again question whether
>> "Obsolete" is an appropriate description for something that's no
>> longer part of the interface (rather than just being suggested to
>> no longer be used). Is there any point in keeping the old sub-op
>> as a comment in the first place?
> 
> To avoid the number being reused.  It also serves as a marker to locate
> the change which removed the hypercall if anyone is doing archaeology in
> the future.

The number getting re-used with a higher interface version is no
problem at all, afaics.

> How about removed instead of obsolete?

That would be fine with me.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel