Am 10.02.2014 10:20, schrieb Markus Armbruster: > Andreas Färber <[email protected]> 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
