[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] QMP's chardev-add less capable than HMP's
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] QMP's chardev-add less capable than HMP's |
Date: |
Wed, 6 Feb 2013 14:40:10 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Wed, Feb 06, 2013 at 03:35:13PM +0100, Markus Armbruster wrote:
> As a general rule, HMP commands must be built on top of the QMP API.
> Luiz and others have worked long & hard to make HMP conform to this
> rule.
>
> However, a new command has crept in that violates it.
>
> QMP's chardev-add runs qmp_chardev_add(), which supports backends
>
> * file with parameters in, out
>
> * port with parameters type (serial, parallel), device
>
> * socket with parameters addr, server, wait, nodelay, telnet
>
> * pty
>
> * null
>
> HMP's chardev-add runs hmp_chardev_add(), which is *not* built on to of
> QMP. Instead, it uses qemu_chr_new_from_opts(), which looks more
> powerful to me. Additional backends: udp, msmouse, vc, memory, pipe,
> stdio, braille, tty, spicevmc, spiceport. I haven't checked whether the
> backends that are available in QMP support all the parameters that HMP
> does.
If the HMP chardev-add was legacy code I could understand having these
two different impls, but given that both the HMP & QMP calls are
brand new code, I agree with you - the HMP impl should be calling the
QMP APIs
> If we're 100% serious about the rule, we need to disable HMP chardev-add
> for the release.
Agreed, either delete the HMP version, or quickly re-write it to work
with the QMP APIs.
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 :|