[Top][All Lists]

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

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

From: Manos Pitsidianakis
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v14 15/21] qom: support non-scalar properties with -object
Date: Wed, 12 Jul 2017 20:56:14 +0300
User-agent: NeoMutt/20170609-57-1e93be (1.8.3)

On Tue, Jul 11, 2017 at 03:49:50PM +0100, Daniel P. Berrange wrote:
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 
>     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.

    -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

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.


This would be useful indeed. If you end up sending the json patch, CC me.

Thanks a lot!

Attachment: signature.asc
Description: PGP signature

reply via email to

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