qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded
Date: Tue, 06 Sep 2011 10:51:26 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

On 09/06/2011 10:45 AM, Jan Kiszka wrote:
On 2011-09-06 16:48, Michael S. Tsirkin wrote:
I'm afraid that won't be enough to stop people
scripting this command - libvirt accessed
HMP for years.

On the other hand, no QMP command means e.g.
libvirt users don't get any benefit from this.

What I think will solve these problems, for both HMP and QMP,
is an explicit 'debug_unstable' or 'debug_unsupported' command that will
expose all kind of debugging functionality making it
very explicit that it's an unsupported debugging utility.

Proposed syntax:

debug_unstable<subcommand>  <options>

Example:

debug_unstable device_show -all

For HMP, this would needlessly complicate the user interface, nothing I
would support. People scripting things on top of HMP are generally doing
this on their own risk and cannot expect output stability.

device_show is like info qtree: the output will naturally change as the
emulated hardware evolves, information is added/removed, or we simply
improve the layout. Recent changes on info network are an example for
the latter.

Yeah, I'm not worried about stability. HMP commands that aren't exposed as QMP commands are inherently unstable and should not be scripted to.

I'm still contemplating how we go about doing this. This series introduces a couple new concepts like QMP class hinting anonymous IDs. I'm concerned that we'll further complicate the need to support backwards compatibility.

Would the command be useful if you couldn't address devices? If it just dumped the full machine state all at once? That would at least obviate the need to add anonymous IDs.

Regards,

Anthony Liguori


Jan





reply via email to

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