On 03/31/2015 01:46 PM, Eduardo Habkost wrote:
> On Mon, Mar 30, 2015 at 04:28:25PM +0200, Michael Mueller wrote:
> [...]
>>  ##
>>  # @query-cpu-definitions:
>>  #
>>  # Return a list of supported virtual CPU definitions
>>  #
>> +# @machine: #optional machine type (since 2.4)
>> +#
>> +# @accel: #optional accelerator id (since 2.4)
>> +#
>>  # Returns: a list of CpuDefInfo
>>  #
>>  # Since: 1.2.0
>>  ##
>> -{ 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'] }
>> +{ 'command': 'query-cpu-definitions',
>> +  'data': { '*machine': 'str', '*accel': 'AccelId' },
>> +  'returns': ['CpuDefinitionInfo'] }
> 
> What happens if the new parameters are provided to an old QEMU version
> that doesn't accept them? It looks like we need an introspection
> mechanism or a new command name.

Providing an optional parameter that a new qemu understands to an older
qemu gracefully errors out about an unknown parameter.  But it's
annoying to have to probe for whether the parameter is understood by
exploiting that particular error message from older qemu.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org