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: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded
Date: Wed, 07 Sep 2011 11:37:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

Am 06.09.2011 19:05, schrieb Michael S. Tsirkin:
> On Tue, Sep 06, 2011 at 11:28:09AM -0500, Anthony Liguori wrote:
>> 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.
> 
> So how, in the end, will user know it's unsupported?
> I don't agree with 'all HMP is unstable' as people
> will use it and will come to depend on it.

Why unsupported? It's just not a stable API to script against. It's a
user interface, not a programming interface. So as long as you use it
manually, that's perfectly fine.

Would you expect that virt-manager never changes its GUI because there
might be some scripts that try to achieve things by screen scraping? The
interface is just not meant for such uses, and if you use it in that way
and it breaks with the next version it's your own fault.

Kevin



reply via email to

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