On Sat, 08 Feb 2014 15:24:05 +0100 Andreas Färber <afaer...@suse.de> wrote:
> 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. Patches with QERR_ are still accepted where it makes sense and user interface expects particular error type/message. In this particular context QERR_INVALID_PARAMETER_TYPE is appropriate since user interface expects this particular error in this context. Luiz wasn't objecting to this specific error case in past: http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00738.html if one greps for QERR_INVALID_PARAMETER_TYPE, visitors are using it extensively and even qom/object.c uses it. > Apart from that issue all patches look okay on brief skimming over. > > Patch 10 should've been slightly more verbose because changing the type > of properties is normally NOT allowed. The reason it is possible here is > because they are format-compatible, which the commit message does not > explain. > > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg > -- Regards, Igor