Re: [libvirt] [PATCH 3/3] libxl: add .domainSendKey

>> On 12/10/2014 at 05:21 PM, in message <20141210092125.GB6450(a)redhat.com&gt;,

On Tue, Dec 09, 2014 at 11:19:22PM -0700, Chun Yan Liu wrote: > > > >>> On 12/9/2014 at 05:44 PM, in message <20141209094444.GB29167(a)redhat.com&gt;, > "Daniel P. Berrange" <berrange(a)redhat.com&gt; 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.) Yes pretty much, but I wouldn't do anything with domainSendKey. Apps can choose to try to use domainSendKey if domainSysRequest isn't supported.

Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|