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