[libvirt] [PATCH 3/3] libxl: add .domainSendKey
Daniel P. Berrange
berrange at redhat.com
Wed Dec 10 09:21:25 UTC 2014
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 at redhat.com>,
> "Daniel P. Berrange" <berrange at 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.)
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 :|
More information about the libvir-list
mailing list