From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57240) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blxhv-000371-NO for qemu-devel@nongnu.org; Mon, 19 Sep 2016 08:30:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1blxhs-0002CJ-FF for qemu-devel@nongnu.org; Mon, 19 Sep 2016 08:29:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57656) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1blxhs-0002Bi-5O for qemu-devel@nongnu.org; Mon, 19 Sep 2016 08:29:56 -0400 Date: Mon, 19 Sep 2016 13:29:51 +0100 From: "Daniel P. Berrange" Message-ID: <20160919122951.GO15201@redhat.com> Reply-To: "Daniel P. Berrange" 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8b859c2b-c06c-76ad-da80-0cbf8b02e6ac@redhat.com> 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: Paolo Bonzini Cc: qemu-devel@nongnu.org, Markus Armbruster , Max Reitz , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Andreas =?utf-8?Q?F=C3=A4rber?= , Kevin Wolf 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=ram-node2,size=24578621440,policy=bind,\ > > host-nodes=1-2,host-nodes=5,host-nodes=7, > > > > 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. 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. The problem I'm facing with the above scenario though occurs before we get anywhere near the visitors, or the crumple step. When qemu_opts_to_qdict() turns QemuOpts into QDict, it looses repeated options. So given a command line -object memory-backend-ram,\ id=ram-node2,size=24578621440,policy=bind,\ host-nodes=1-2,host-nodes=5,host-nodes=7, we're getting an initial QDict containing type=memory-backend-ram id=ram-node2 size=24578621440 policy=bind host-nodes=7 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 type=memory-backend-ram id=ram-node2 size=24578621440 policy=bind host-nodes.0=1-2 host-nodes.1=5 host-nodes.2=7 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. 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 :|