qemu-devel
[Top][All Lists]
Advanced

[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: Anthony Liguori
Subject: Re: [Qemu-devel] QMP's chardev-add less capable than HMP's
Date: Wed, 06 Feb 2013 09:16:52 -0600
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Gerd Hoffmann <address@hidden> writes:

> On 02/06/13 15:35, 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.
>
> Future plan is to add support for the missing ones to QMP,
> then switch over qemu_chr_new_from_opts to create ChardevBackend and use
> the new QMP code path for initialization everywhere.  Once this point is
> reached both HMP and QMP will provide identical features.
>
> Obviously that isn't an option for 1.4.
>
>> If we're 100% serious about the rule, we need to disable HMP chardev-add
>> for the release.
>
> Fine with me.

Ack.

Regards,

Anthony Liguori

> cheers,
>   Gerd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]