From: "Daniel P. Berrange" <berrange@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.