[libvirt] [PATCH 2/4] Specify remote protocol for virDomainSendProcessSignal

[Eric Blake]

> From: "Daniel P. Berrange" <berrange at redhat.com>
> 
> * src/remote/remote_protocol.x: message definition
> * src/remote/remote_driver.c: Register driver function
> * src/remote_protocol-structs: Test case

Of course, this all depends on any changes made to 1/4 based
on my review there; but it is fairly mechanical and matches
(for now).  However...

> +++ b/src/remote/remote_driver.c
> @@ -6124,6 +6124,7 @@ static virDriver remote_driver = {
>      .domainMigrateFinish3 = remoteDomainMigrateFinish3, /* 0.9.2 */
>      .domainMigrateConfirm3 = remoteDomainMigrateConfirm3, /* 0.9.2
>      */
>      .domainSendKey = remoteDomainSendKey, /* 0.9.3 */
> +    .domainSendProcessSignal = remoteDomainSendProcessSignal, /*
> 0.9.8 */

s/0.9.8/1.0.1/

> @@ -3026,7 +3033,8 @@ enum remote_procedure {
>  
>      REMOTE_PROC_NETWORK_UPDATE = 291, /* autogen autogen
>      priority:high */
>      REMOTE_PROC_DOMAIN_EVENT_PMSUSPEND_DISK = 292, /* autogen
>      autogen */
> -    REMOTE_PROC_NODE_GET_CPU_MAP = 293 /* skipgen skipgen */
> +    REMOTE_PROC_NODE_GET_CPU_MAP = 293, /* skipgen skipgen */
> +    REMOTE_PROC_DOMAIN_SEND_PROCESS_SIGNAL = 294 /* autogen autogen
> priority:high */

Is this right?  If we implement this via a guest agent command for
qemu, then we must block waiting for a response from the agent,
at which point I think we can no longer guarantee high priority.