From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O51RZ-0000tf-4Q for qemu-devel@nongnu.org; Thu, 22 Apr 2010 14:48:09 -0400 Received: from [140.186.70.92] (port=50597 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O51RV-0000sC-8j for qemu-devel@nongnu.org; Thu, 22 Apr 2010 14:48:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O51RS-0006Cd-1Q for qemu-devel@nongnu.org; Thu, 22 Apr 2010 14:48:03 -0400 Received: from mail-pv0-f173.google.com ([74.125.83.173]:50232) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O51RR-0006CP-Sa for qemu-devel@nongnu.org; Thu, 22 Apr 2010 14:48:02 -0400 Received: by pvg2 with SMTP id 2so264284pvg.4 for ; Thu, 22 Apr 2010 11:48:00 -0700 (PDT) Message-ID: <4BD099DB.8030407@codemonkey.ws> Date: Thu, 22 Apr 2010 13:47:55 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [libvirt] [Qemu-devel] Re: Libvirt debug API References: <4BBF2E93.3020508@redhat.com> <20100409142717.GA11875@redhat.com> <20100409210650.GA31666@shareable.org> <20100411202823.GB26291@amd.home.annexia.org> <20100411221738.GA27990@shareable.org> <20100412085621.GN26162@redhat.com> <20100412122308.GD18075@shareable.org> In-Reply-To: <20100412122308.GD18075@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Libvirt , Jiri Denemark , qemu-devel@nongnu.org, "Richard W.M. Jones" On 04/12/2010 07:23 AM, Jamie Lokier wrote: > Daniel Veillard wrote: > >> On Sun, Apr 11, 2010 at 11:17:38PM +0100, Jamie Lokier wrote: >> >>> It's not that hard to write this for trivial extra options: >>> >>> /bin/sh -c 'qemu "$0" "$@" -extra-flag' >>> >>> (if that works). >>> >> That won't work because we expect the emulator to be a path to >> the emulator program, so yes that has to be done in the wrapper script. >> > Ok. Being able to pass arguments would be about infinitely more > useful, so that you don't need a separate wrapper script for every > individual guest configuration - you can pass options to the single > wrapper for each variation. > > Even/path/to/wrapper qemu-0.11 is a big improvement > over/path/to/wrapper-guest-config-6-with-qemu-0.11 ;-) > > Some simple but versatile hook ideas: > > - (no space splitting, one option, appended) > - (space splitting multiple options) > - > - > -VALUE > I'd strongly suggest not focusing on manipulating command line arguments. I think in the not too distant future, few people will pass command line arguments as opposed to just using configuration files. We are very close to being able to cover 90% of current users via the config file. Regards, Anthony Liguori > -/path/to/script > This last one is to call the script, but pass all the options > including the path to whichever version of qemu/kvm would get > selected by libvirt. (I presume it has some selection mechanism, > given the variety of guests which break with each version of qemu > and/or qemu-kvm and/or kvm?) > > (It is most unfortunate that XML forces those long prefixes everywhere > due to lack of contextual naming, unlike less verbose config formats :-/) > > >>> Parsing libvirt output and having to guess which option corresponds to >>> what from the libvirt config sounds very fragile and also a rather >>> large amount of effort for something which should be easy. >>> >> it's not that easy because we change the way we build the command line >> for qemu as qemu evolves. for example before and after the support for >> -device there have been a lot of changes. >> > I agree, which is why it's much less fragile if libvirt provides the > individual parts to hooks/wrappers, if that's asked, rather than > forcing the wrapper to parse libvirts output and guess what libvirt > does from version to version. > > For sure, before and after -device, any script which is involved with > those options will probably have to change. But that's quite unusual. > Most usually I'd expect things like the order of -device options might > change depending on how libvirt pulled together it's backing > resources, for example. > > -- Jamie > > >