qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control mode
Date: Tue, 23 Jun 2009 13:53:44 +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

Avi Kivity wrote:
> 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.

That was my personal interpretation, maybe based on incomplete information.

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

Yes.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux




reply via email to

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