[Top][All Lists]

[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: Avi Kivity
Subject: [Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control mode
Date: Tue, 23 Jun 2009 14:51:18 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2

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

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

reply via email to

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