[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: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded |
Date: |
Tue, 06 Sep 2011 18:29:13 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
On 2011-09-06 18:09, 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?
> Which means almost all cases I care about: debugging on my laptop
> I can easily attach with gdb and inspect state.
HMP passthrough or - I bet that's what you rather want - monitor
passthrough from gdb.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
- Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded, (continued)
- Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded, Michael S. Tsirkin, 2011/09/06
- Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded, Anthony Liguori, 2011/09/06
- Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded, Michael S. Tsirkin, 2011/09/06
- Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded, Kevin Wolf, 2011/09/07
- Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded, Michael S. Tsirkin, 2011/09/07
- Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded, Jan Kiszka, 2011/09/07
- Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded, Michael S. Tsirkin, 2011/09/07
- Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded, Anthony Liguori, 2011/09/07
- Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded, Jan Kiszka, 2011/09/07
- Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded, Michael S. Tsirkin, 2011/09/07
- Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded,
Jan Kiszka <=