From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36875) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SunVt-0007BA-Rs for qemu-devel@nongnu.org; Fri, 27 Jul 2012 12:35:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SunVn-0007op-Mo for qemu-devel@nongnu.org; Fri, 27 Jul 2012 12:35:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63175) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SunVn-0007oF-Eq for qemu-devel@nongnu.org; Fri, 27 Jul 2012 12:35:35 -0400 Date: Fri, 27 Jul 2012 17:35:28 +0100 From: "Daniel P. Berrange" Message-ID: <20120727163528.GA2742@redhat.com> References: <1343245677-20904-1-git-send-email-aliguori@us.ibm.com> <20120726124723.GG12180@redhat.com> <87394dqwh4.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87394dqwh4.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH] vl: add -libvirt-caps option for libvirt to stop parsing help output Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Peter Maydell , Anthony Liguori , Eric Blake , qemu-devel@nongnu.org On Fri, Jul 27, 2012 at 01:23:03PM +0200, Markus Armbruster wrote: > "Daniel P. Berrange" writes: > > The above would take care of probably 50% of the current libvirt > > capabilities probing, including a portion of the -help stuff. Then > > there is all the rest of the crap we detect from the -help. We could > > just take the view, that "as of 1.2", we assume everything we previously > > detected is just available by default, and thus don't need to probe > > it. For stuff that is QOM based, I expect we'll be able to detect new > > features in the future using the qom-XXX monitor commands. For stuff > > that is non-qdev, and non-qom, libvirt can just do a plain version > > number check, unless we decide there is specific info worth exposing > > via other new 'query-XXX' monitor commands. > > Assuming version X (according to query-version) supports no less than > upstream version X sounds fair. > > If a command line option has a corresponding QMP command, probing QMP > for the feature suffices. For instance, query-devices gives you devices > for -device. > > I'm afraid there could still be an occasional need for probing the > command line. A simple, machine-readable command line self-description > could satisfy it. Something like: > > - query-cmdline-options: JSON representation of qemu_options[], with > unnecessary detail elided. Basically option name and whether it takes > an argument. > > For options with a QemuOpts argument, we may want to add argument > self-description. Basically its QemuOptsList, with unnecessary detail > elided. Non-QemuOpts arguments don't get that. New structured option > arguments should use QemuOpts anyway. I think you are quite possibly correct, but for the sake of enabling us to move forward without more arguments, my inclination is to ignore this just now :-) Lets get the new commands Anthony posted merged, and port libvirt to use this new approach. Once that's all done, we can evaluate whether there is a any more information we ought to provide which might require a query-cmdline-options, or something else more targetted (eg query-chardev-options or something) Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|