[Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control mode

[Avi Kivity <avi@redhat.com>]

On 06/23/2009 02:44 PM, Jan Kiszka wrote:
>> I'm not saying it's impossible, just that we don't want to do it.
>>      
>
> I agree it's not something that is mandatory for the first versions, but
> disagree that we should not strive for achieving this level of support
> mid- to long-term. No design decision made today should prevent it, but
> rather keep that door open. Also for robustness reasons (if you loose
> contact to your qemu backend and need to resync the management frontend).
>    

No objections here.  Certainly reconnect is important.
>> If libvirt "doesn't bother" about something useful, that's a libvirt
>> bug.  It's wierd to have something controlled by two parallel management
>> channels.
>>      
>
> I think the libvirt policy is that things which are not generic enough
> to be supported by>1 hypervisor are left alone.
>    

That's a bit offtopic here, but it appears to me this dooms libvirt to 
be useless in all but the most basic use cases.  Hypervisor writers try 
to new features to differentiate their products, and forcing users off 
libvirt in order to use them seems to be counterproductive.

>>> See, I don't want to kill my management app just because I attached to a
>>> guest via gdb and start injecting reconfiguration events for testing
>>> purposes (e.g. attach/detach a USB device for which I develop a driver).
>>>
>>>        
>> You're talking about a usb developer, not a qemu developer, working in
>> some virtual lab environment?  In that case, libvirt and the management
>> app should certainly support usb.  A random usb developer shouldn't need
>> to ever talk to the qemu monitor.
>>      
>
> I'm talking about, just as one example, sitting in front of my gdb
> [frontend], doing guest kernel [driver] debugging and issuing "monitor
> whatever" commands from one place, ie. not having to switch between
> management app and debugging interface back and forth.
>    

Can gdb issue monitor commands?

-- 
error compiling committee.c: too many arguments to function