Re: [Qemu-devel] QMP's chardev-add less capable than HMP's

[Luiz Capitulino]

On Wed, 06 Feb 2013 16:28:08 +0100
Paolo Bonzini <address@hidden> wrote:

> Il 06/02/2013 15:35, Markus Armbruster ha scritto:
> > 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 we're 100% serious about the rule, we need to disable HMP chardev-add
> > for the release.
> > 
> > Are we?
> 
> It is not hmp_chardev_add() that is not built on QMP, it is
> qemu_chr_new_from_opts().
> 
> It is qemu_chr_new_from_opts() that we want to convert to the QMP API
> once the QMP API is powerful enough.  The implementation of HMP
> shouldn't need any change.
> 
> Something along these lines is the reason why the more-powerful HMP
> command was "allowed" by Luiz.

Yes, I did and I'm sorry for that.

When we had that discussion, the context I had in mind was whether or not
to allow HMP to temporarily make non-QMP calls. As I hadn't fully reviewed
the series, I really didn't know that the HMP command would end up different
in terms of capabilities; and honestly didn't expect it would be more powerful.

I agree that the best solution is to disable the QMP command for 1.4.