On Wed, 06 Feb 2013 16:28:08 +0100 Paolo Bonzini <pbonz...@redhat.com> 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.
