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

["Andreas Färber" <afaerber@suse.de>]

Am 10.02.2014 10:20, schrieb Markus Armbruster:
> Andreas Färber <afaerber@suse.de> 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.

Guess that's one of the social aspects again: My lack of response does
not mean "I'm okay with it" but rather "I haven't read it yet or am
investigating alternatives", and I assume the same for other people. ;)

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

OK, I still don't fully understand the logic why sometimes we shouldn't
use QERR_ at all, in some cases inline the error message for
compatibility without reusing the QERR_ and sometimes can use QERR_
directly, but I don't mind it getting applied that way - QERR_ is not my
fight. :)

Since Peter has not pulled yet, I'll pull or apply into my tree to check
if anything collides.

Cheers,
Andreas

E.g.,
http://repo.or.cz/w/qemu.git/commit/d44bb8604e87ecd3823f12f0c92d5e56d613de0d
(which collided with the QOM realize conversion so that I noticed)

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg