>> On 12/9/2014 at 05:44 PM, in message
<20141209094444.GB29167(a)redhat.com>,
"Daniel P. Berrange"
<berrange(a)redhat.com> wrote:
On Tue, Dec 09, 2014 at 11:27:46AM +0800, Chunyan Liu wrote:
> libxl supports sysrq. Add .domainSendKey function to support
> sending sysrq key.
I think this is really bending the semantics of the virDomainSendKey
API too much. This API is documented to inject *any* scancodes into
the guest operating system. Implementing it in such a way that you
can only send sysrq key sequences to the guest kernel is not what
applications will expect when they try to use this API. So NACK to
this patch
I'm open to the idea of adding an explicit API for triggering the
sysrq sequence though. eg virDomainSendSysRequest or something
like that, if you really want access to sysrq via the API.
Libxl now has no ability to send any key sequence to guest kernel
but supports sending sysrq key. We just want a way to send sysrq key,
so adding new virDomainSendSysRequest API is OK to me.
Meanwhile, that means:
Adding .domainSendSysRequest to virHypervisorDriver?
And in virsh, add a new 'virsh sysrq' command or update code of
cmdSendKey to handle sysrq key sequence? (like if .domainSendKey is
not supported by driver, check if it is sysrq key sequence, if yes, try
virDomainSysRequest if driver supports that.)
Thanks,
Chunyan