From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blxrm-0001XW-VL for qemu-devel@nongnu.org; Mon, 19 Sep 2016 08:40:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1blxri-0005Wy-Pj for qemu-devel@nongnu.org; Mon, 19 Sep 2016 08:40:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59734) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blxri-0005WW-GJ for qemu-devel@nongnu.org; Mon, 19 Sep 2016 08:40:06 -0400 References: <1474286310-6922-1-git-send-email-berrange@redhat.com> <1474286310-6922-7-git-send-email-berrange@redhat.com> <20160919121211.GN15201@redhat.com> <8b859c2b-c06c-76ad-da80-0cbf8b02e6ac@redhat.com> <20160919122951.GO15201@redhat.com> From: Paolo Bonzini Message-ID: Date: Mon, 19 Sep 2016 14:40:01 +0200 MIME-Version: 1.0 In-Reply-To: <20160919122951.GO15201@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v13 6/6] qom: support arbitrary non-scalar properties with -object List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org, Markus Armbruster , Max Reitz , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= , =?UTF-8?Q?Andreas_F=c3=a4rber?= , Kevin Wolf On 19/09/2016 14:29, Daniel P. Berrange wrote: > On Mon, Sep 19, 2016 at 02:19:19PM +0200, Paolo Bonzini wrote: >> >> >> On 19/09/2016 14:12, Daniel P. Berrange wrote: >>> On Mon, Sep 19, 2016 at 12:58:30PM +0100, 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. >>>> >>>> Fortunately there is no existing object that implements >>>> the UserCreatable interface that relies on the list >>>> handling behaviour, so it is possible to swap out the >>>> OptsVisitor for a different visitor implementation, so >>>> -object supports non-scalar properties, thus leaving >>>> other users of OptsVisitor unaffected. >>> >>> Urgh, I've just discovered that this is not in fact true. >>> >>> The 'memory-backend' object type uses uint16List which >>> has the hacky list syntax >>> >>> -object memory-backend-ram,\ >>> id=3Dram-node2,size=3D24578621440,policy=3Dbind,\ >>> host-nodes=3D1-2,host-nodes=3D5,host-nodes=3D7, >>> >>> So I'll need to figure out a way to preserve this syntax... >> >> Is there a usecase for qdict_crumple without the following >> de-stringification pass? If not, qdict_crumple could use a >> StringInputVisitor on the values directly. >=20 > I'm not sure I understand how that would help and in any case, the > string-input-visitor itself is incapable of dealing with compound > properties. > It too could/should be ultimately replaced by the > qobject-input-visitor combined with a pre-processing step to > turn the input string into a qdict. >=20 > The problem I'm facing with the above scenario though occurs > before we get anywhere near the visitors, or the crumple step. >=20 > When qemu_opts_to_qdict() turns QemuOpts into QDict, it looses > repeated options. Ouch, I thought the problem was only with "1-2", not with the repeated host-nodes. Wow, that does really work?!? What might work is if you convert the repeated options to "host-nodes=3D1-2,5,7". Then StringInputVisitor is able to parse that (but OptsVisitor isn't). I'm not sure if there are other uses of repeated options. Probably not based on a limited inspection of callers of qemu_opt_foreach. Paolo > What I need to do is make qemu_opts_to_qdict more intelligent > so that if it sees repeated strings, it inserts them into the > qdict using list index style. eg, the QemuOpts -> QDict > conversion should have at minimum given us >=20 > type=3Dmemory-backend-ram > id=3Dram-node2 > size=3D24578621440 > policy=3Dbind > host-nodes.0=3D1-2 > host-nodes.1=3D5 > host-nodes.2=3D7 >=20 > although even then there's some magic in the range value seen there. I'= m > unclear on whether we should try to deal with the range "1-2" in the > qemu_opts_to_qdict() method, the qdict_crumple() method or the qobject > input visitor code for parsing ints. >=20 > Regards, > Daniel >=20