[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 03/28] libxl: Provide libxl__dm_support_*
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@xxxxxxxxxxxxx >> http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |