Re: [Xen-devel] [PATCH 03/28] libxl: Provide libxl__dm_support_*

[Jim Fehlig <jfehlig@xxxxxxxx>]

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