Re: [Qemu-devel] [PATCH v2 0/6] Stable output of blockdev format specific info

[Daniel P. Berrange]

On Tue, Sep 13, 2016 at 03:44:21PM +0200, Markus Armbruster wrote:
> "Daniel P. Berrange" <address@hidden> writes:
> 
> > This is an update of the bits of this previous
> > series which were not merged
> >
> >   https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg01723.html
> >
> > The problem addressed in this series is that the
> > 'qemu-img info' command does not have a stable
> > output format for the image specific info objects.
> >
> > The QAPI types are first converted to QDicts,
> > and then printed with custom code to recurse over
> > the QDicts. This causes information about the object
> > field ordering to be thrown away, and fields are
> > printed in whatever order they appear in the QDict
> > hash buckets. This is not a big deal historically
> > since none of the image formats had nested data
> > structures, but with the LUKS blockdev this style
> > of random ordering looks very unpleasant.
> 
> QDict could be changed to support iteration in insertion order.

True, at the cost of extra data storage for each QDict
to maintain details of the insertion order of its keys.

> > To address this, the patch series introduces a
> > TextOutputVisitor class that is designed to be
> > able to print out arbitrarily nested QAPI types
> > directly,
> 
> What order does it use?

It uses whatever order the generated visitor visits
in, which AFAICT, is the same order in which fields
are declared in the QAPI schema struct definitions.

> 
> >           in a format that is identical to that
> > currently used with 'qemu-img info'. Consult
> > the patch in question to actually see the output
> > format, and compare test-string-output-visitor.c
> > with test-text-output-visitor.c to see how we
> > really do have 2 completely distinct output formats
> > that don't share any significant characteristics
> > beyond both being "plain text".
> 
> I haven't done that, yet, but I take your word for it.  Begs the
> question whether we really *need* two different output formats!  I guess
> we better discuss that in the context of the patch, where we can
> actually see the formats.

Since posting this I have been looking at where string-{input,output}-visitor
is used, and I think there is probably scope for eliminating many uses,
and converting other uses to text-output-visitor. It might even be possible
to get everything able to use text-output-visitor with a little work, at
which point we might as well call it string-output-visitor again ;-)
Investigation is ongoing.... The main point is all around the code which
special cases lists of ints in string input/ouput visitor :-(

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|