qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [PATCH v3 03/10] qom: support arbitrary no


From: Daniel P. Berrange
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v3 03/10] qom: support arbitrary non-scalar properties with -object
Date: Tue, 22 Mar 2016 10:34:17 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

On Tue, Mar 22, 2016 at 10:07:42AM +0100, Markus Armbruster wrote:
> Eric Blake <address@hidden> writes:
> 
> > On 03/10/2016 11:59 AM, Daniel P. Berrange wrote:
> >> The current -object command line syntax only allows for
> >> creation of objects with scalar properties, or a list
> >> with a fixed scalar element type. Objects which have
> >> properties that are represented as structs in the QAPI
> >> schema cannot be created using -object.
> >> 
> >> This is a design limitation of the way the OptsVisitor
> >> is written. It simply iterates over the QemuOpts values
> >> as a flat list. The support for lists is enabled by
> >> allowing the same key to be repeated in the opts string.
> >> 
> >> It is not practical to extend the OptsVisitor to support
> >> more complex data structures while also maintaining
> >> the existing list handling behaviour that is relied upon
> >> by other areas of QEMU.
> >
> > Zoltán Kővágó tried earlier with his GSoC patches for the audio
> > subsystem last year, but those got stalled waiting for qapi enhancements
> > to go in.
> 
> Yet another series stalled on the big QAPI rework.  Hitting a GSoC
> student that way is really unfortunate.
> 
> >            But I think your approach is indeed a bit nicer (rather than
> > making the warty OptsVisitor even wartier, just avoid it).
> 
> QemuOpts defines an important part of the command line language, namely
> (most of) the syntax of many option arguments.  It parses them into a
> set of (name, value) pairs.
> 
> "Most of", because additional syntax may hide in the parameter value.
> 
> Parameter values are typed, except when they aren't.  Types are limited
> to string, bool, uint64_t number (accepts negative numbers and casts
> them) and uint64_t size (rejects negative numbers, accepts suffixes).
> 
> OptsVisitor adds special list syntax.  It's used with untyped values.
> 
> Bypassing OptsVisitor risks adding different special syntax.  Doesn't
> mean it's a bad idea, only that we need to keep close watch on what it
> does to the language.  See below.

FWIW, when I first started attacking this problem I actually went down
the path of extending the OptsVisitor to cope with arbitrarily nested
structs + lists. I quickly discovered that special list syntax supported
by the OptsVisitor. I tried to hack support for nested structs + lists
on top of that, but ultimately the way the special list syntax is designed
makes that an impossible problem without breaking back compat, or having
OptsVisitor support two completely different lists syntaxes at the same
time with ambiguous parsing results. None the less I did implement that
all and it was a huge amount of work. I then took a look at QMPInputVisitor
and realized that if we could converts a QemuOpts into a QDict, we could
just reuse the QMPInputVisitor.

In the specific case of -object the fact that QMPInputVisitor does not
support the special list syntax from OptsVisitor is not a problem because
we don't have any existing user defined object type that uses list props
yet. So if we want to change -object from OptsVisitor to QMPInputVisitor
the sooner we change it the better - it is only a matter of time before
something comes along that depends on the existing special list syntax
and then we'll be locked into OptsVisitor's non-extensible approach.

> >> Would be creatable via the CLI now using
> >> 
> >>     $QEMU \
> >>       -object demo,id=demo0,\
> >>               foo.0.bar=one,foo.0.wizz=1,\
> >>               foo.1.bar=two,foo.1.wizz=2
> 
> Okay, this adds a bare minimum of syntax, and it's not even new: we use
> similar syntax for block stuff already.

Yes, indeed that usage by the block layer is what motivated me to ditch
OptsVisitor and take the approach of converting QemuOpts to QDict and
then using QMPInputVisitor.

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 :|



reply via email to

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