From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: [PATCH 03/28] libxl: Provide libxl__dm_support_* Date: Fri, 15 Jan 2016 07:54:10 -0700 Message-ID: <56990812.3000009@suse.com> References: <1450809903-3393-1-git-send-email-ian.jackson@eu.citrix.com> <1450809903-3393-4-git-send-email-ian.jackson@eu.citrix.com> <1452186813.21055.262.camel@citrix.com> <5693DFBB.7050701@suse.com> <1452766450.2185.4.camel@citrix.com> <5697E98E.6030008@suse.com> <1452851804.32341.47.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1452851804.32341.47.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Ian Jackson , xen-devel@lists.xensource.com, Wei Liu , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 01/15/2016 02:56 AM, Ian Campbell wrote: > On Thu, 2016-01-14 at 11:31 -0700, Jim Fehlig wrote: >> Ian Campbell wrote: >>> On Mon, 2016-01-11 at 10:00 -0700, Jim Fehlig wrote: >>>> On 01/07/2016 10:13 AM, Ian Campbell wrote: >>>>> On Tue, 2015-12-22 at 18:44 +0000, Ian Jackson wrote: >>>>>> This allows code elsewhere in libxl to find out what options a >>>>>> device >>>>>> model executable supports. This is done by searching the usage >>>>>> message for fixed strings. >>>>> Has anyone (ever, not necessarily a Xen person nor in this context) >>>>> approached upstream QEMU about a machine readable output of some >>>>> sort? >>>>> >>>>> I know libvirt does something similar to this, but they want to >>>>> support >>>>> older versions, whereas we at least have the luxury of not caring >>>>> about >>>>> versions before the point this code lands. >>>> Since qemu 1.2.0, libvirt has been using the various QMP commands to >>>> probe for >>>> qemu capabilities, instead of parsing help output. >>> As in it spawns a qemu specifically to ask the questions and then kills >>> it >>> and starts what it needs _or_ it starts the qemu with minimal command >>> line >>> cfg and then dynamically pokes in the full config via qmp? >> The latter. > From the description I think you meant former? Yes :-). Brain thought one way, fingers typed another... Regards, Jim > >> When the qemu driver loads, it starts qemu, pokes it for >> capabilities via qmp, caches what it finds, then terminates it. The cached >> capabilities are used until the associated qemu binary is changed/updated. >> >> If interested in peeking at the code, see virQEMUCapsInitQMP() and the functions >> it calls in $libvirt_src/src/qemu/qemu_capabilities.c. E.g. >> >> virQEMUCapsInitQMP() >> -> virQEMUCapsInitQMPMonitor() >> -> virQEMUCapsInitQMPBasic() > Thanks. > > When I spoke to Ian J yesterday we decided doing this properly (via QMP as > above) would be nice it was out of scope for this series for now. It would > make a nice future bit of cleanup though for sure. > > Ian. > >> Regards, >> Jim >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel