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

[Anthony Liguori <anthony@codemonkey.ws>]

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>
>>>>
>>>> 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.
>
> 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.

Regards,

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.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>>
>>> Jan
>>>
>