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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 22/01/18 13:01, Jan Beulich wrote:
>>>> On 22.01.18 at 13:52, <andrew.cooper3@citrix.com> wrote:
>> On 22/01/18 12:41, Jan Beulich wrote:
>>>>>> On 19.01.18 at 20:19, <andrew.cooper3@citrix.com> 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.

If that change is backported to 4.10, that is the time to burn another
interface version.  Not in this patch.

Also, this demonstrates the inherent problems with the interface
version.  This trick can only ever be played on the most recently
released branch.  It is a dire trainwreck in terms of versioning, and
serves only to make it almost impossible to make changes to an installed
system.

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

Yes it is.  do_domctl() (which inserts the domctl version) is remote
from the choice of op to use, so reusing numbers means that the language
subs around libxc can issue completely erroneous hypercalls without
suffering a build or version failure.  (Again, see trainwreck of a
versioning scheme.)

~Andrew

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