Re: [Qemu-devel] [PATCH v14 15/21] qom: support non-scalar properties with -object

[Daniel P. Berrange]

On Tue, Jul 11, 2017 at 04:44:46PM +0200, Markus Armbruster wrote:
> Markus Armbruster <address@hidden> writes:
> 
> > Manos Pitsidianakis <address@hidden> writes:
> >
> >> Is there a specific reason this patch wasn't finished? If I'm not
> >> wrong using non-scalar properties with -object is still not possible,
> >> yet would be a very useful feature for drivers with UserCreatable
> >> objects.
> >>
> >> Archive link since this is an old patch:
> >> https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg08252.html
> >
> > Yes, we want non-scalar properties with -object.
> >
> > This series attempts to provide them by extending QemuOpts.  The trouble
> > is that we've already pushed QemuOpts beyond its design limits, and this
> > series pushes it some more.  We need to stop working around the design
> > limits of QemuOpts and start replacing them by something that serves our
> > current needs, as I explained in:
> >
> >     Subject: Re: [PATCH v14 00/19] QAPI/QOM work for non-scalar object 
> > properties
> >     Message-ID: <address@hidden>
> >     https://lists.gnu.org/archive/html/qemu-devel/2016-10/msg04895.html
> >
> > I started the replacement work (merge commit 8746709).  It provides
> > non-scalar properties for -blockdev.  I stole Dan's PATCH 07 for it,
> > which became commit cbd8acf.  See also the design thread
> >
> >     Subject: Non-flat command line option argument syntax
> >     Message-ID: <address@hidden>
> >     https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg00555.html
> >
> > PATCH 02-06 have been merged separately (merge commit ede0cbe).
> >
> > More work is needed to apply the solution for -blockdev to -object, and
> > I intend to work on it.  A main difficulty is backwards compatibility to
> > all the ill-designed / accidental QemuOpts warts.  We may have to accept
> > some incompatibility to make progress.
> 
> Waiting for that work to be completed may be less than ideal for you.
> Perhaps we can crack the simple part of the problem quickly, so you can
> play with it while I still work on the harder parts.
> 
> Simple part: -object argument in JSON syntax, exactly as in QMP.
> Example:
> 
>     -object '{ "qom-type": "memory-backend-ram", "id": "mem1", "props": { 
> "size": 4096 } }'
> 
> Non-scalar members of "props" should just work there.
> 
> Hard part: non-scalar properties in the traditional KEY=VALUE syntax,
> using dotted key convention.
> 
> Sketch appended.  If this would be useful for you, I can prepare proper
> patches.

Seems reasonable to enable the JSON syntax right now, as long as we are
confident it'll not need changes once we do the key/val syntax change too.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|