qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 00/14] Cleanup qdev legacy properties


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PULL 00/14] Cleanup qdev legacy properties
Date: Mon, 10 Feb 2014 10:20:29 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Andreas Färber <address@hidden> writes:

> Paolo,
>
> Am 08.02.2014 11:01, schrieb Paolo Bonzini:
>> Anthony, Peter,
>> 
>> The following changes since commit 0169c511554cb0014a00290b0d3d26c31a49818f:
>> 
>>   Merge remote-tracking branch 'qemu-kvm/uq/master' into staging (2014-01-24 
>> 15:52:44 -0800)
>> 
>> are available in the git repository at:
>> 
>>   git://github.com/bonzini/qemu.git qdev-props
>> 
>> for you to fetch changes up to 94fb9add077db8a8f0be3796f44785694c4686bb:
>> 
>>   qapi: refine human printing of sizes (2014-02-08 10:44:41 +0100)
>> 
>> ----------------------------------------------------------------
>> Paolo Bonzini (14):
>>       qapi: add size parser to StringInputVisitor
>>       qdev: sizes are now parsed by StringInputVisitor
>>       qdev: remove legacy parsers for hex8/32/64
>>       qdev: legacy properties are now read-only
>>       qdev: legacy properties are just strings
>>       qdev: inline qdev_prop_parse
>>       qapi: add human mode to StringOutputVisitor
>>       qdev: use human mode in "info qtree"
>>       qdev: remove most legacy printers
>>       qdev: remove hex8/32/64 property types
>>       block: handle "rechs" and "large" translation options
>>       qdev: add enum property types to QAPI schema
>>       qdev: use QAPI type names for properties
>>       qapi: refine human printing of sizes
>
> I had specifically requested to review and take these through qom-next,
> like most qdev changes have gone lately. Why are you sending a pull
> nontheless? In particular Luiz has not yet replied to the QERR issue I
> pointed out.

I guess Luiz didn't reply for the same reason I didn't chime in then:
Paolo and Eric explained the use of QERR_INVALID_PARAMETER_TYPE
adquately.

You're right to challenge new uses of QERR_*, but the use you spotted is
appropriate, since we want consistency with the existing visitors.

[...]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]