> From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
>
> * 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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list