[Top][All Lists]

[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 11:28:09 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

On 09/06/2011 11:09 AM, Michael S. Tsirkin wrote:
On Tue, Sep 06, 2011 at 10:51:26AM -0500, Anthony Liguori wrote:
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>


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.

They are also not accessible when using libvirt, right?

$ virsh human-monitor-passthrough GuestName device_show foo

Should work.

Which means almost all cases I care about: debugging on my laptop
I can easily attach with gdb and inspect state.

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.

Dazed and confused. Above you stated these commands are
inherently unstable and no need to support?

Right, my concern is that the unstable command results in changes that are visible in stable interfaces. As Jan suggested, we could try to hide this from those commands but that seems a bit ugly to me.


Anthony Liguori

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.


Anthony Liguori


reply via email to

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