Re: [Xen-devel] [PATCH 2/4] tools/libxc: Define VM_EVENT type

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.09.18 at 17:01, <ppircalabu@xxxxxxxxxxxxxxx> wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -757,10 +757,17 @@ struct xen_domctl_gdbsx_domstatus {
>  
>  /*
>   * There are currently three rings available for VM events:
> - * sharing, monitor and paging. This hypercall allows one to
> - * control these rings (enable/disable), as well as to signal
> - * to the hypervisor to pull responses (resume) from the given
> - * ring.
> + * sharing, monitor and paging
> + */
> +
> +#define XEN_VM_EVENT_TYPE_PAGING 1
> +#define XEN_VM_EVENT_TYPE_MONITOR 2
> +#define XEN_VM_EVENT_TYPE_SHARING 3
> +
> +/*
> + * This hypercall allows one to control the vm_event rings (enable/disable),
> + * as well as to signal to the hypervisor to pull responses (resume) from
> + * the given ring.
>   */

What's the reason to modify the comment, the more with a style
violation (malformed single line comment) as the result?

> @@ -780,7 +787,7 @@ struct xen_domctl_gdbsx_domstatus {
>   * EXDEV  - guest has PoD enabled
>   * EBUSY  - guest has or had paging enabled, ring buffer still active
>   */
> -#define XEN_DOMCTL_VM_EVENT_OP_PAGING            1
> +#define XEN_DOMCTL_VM_EVENT_OP_PAGING XEN_VM_EVENT_TYPE_PAGING
>  
>  /*
>   * Monitor helper.
> @@ -804,7 +811,7 @@ struct xen_domctl_gdbsx_domstatus {
>   * EBUSY  - guest has or had access enabled, ring buffer still active
>   *
>   */
> -#define XEN_DOMCTL_VM_EVENT_OP_MONITOR           2
> +#define XEN_DOMCTL_VM_EVENT_OP_MONITOR XEN_VM_EVENT_TYPE_MONITOR
>  
>  /*
>   * Sharing ENOMEM helper.
> @@ -819,7 +826,7 @@ struct xen_domctl_gdbsx_domstatus {
>   * Note that shring can be turned on (as per the domctl below)
>   * *without* this ring being setup.
>   */
> -#define XEN_DOMCTL_VM_EVENT_OP_SHARING           3
> +#define XEN_DOMCTL_VM_EVENT_OP_SHARING XEN_VM_EVENT_TYPE_SHARING

And what's the reason to retain these (now redundant)
XEN_DOMCTL_VM_EVENT_OP_* definitions? Either they're independent
(in which case they shouldn't resolve to XEN_VM_EVENT_TYPE_*) or
they're true aliases (tolerating arbitrary future changes to
XEN_VM_EVENT_TYPE_* without further adjustment here), and then
unnecessary to retain.

Jan



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