From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43888) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCp9W-0006FT-1v for qemu-devel@nongnu.org; Tue, 14 Jun 2016 10:17:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCp9Q-0000J0-OM for qemu-devel@nongnu.org; Tue, 14 Jun 2016 10:17:12 -0400 Date: Tue, 14 Jun 2016 15:16:56 +0100 From: "Daniel P. Berrange" Message-ID: <20160614141656.GU4310@redhat.com> Reply-To: "Daniel P. Berrange" References: <1464885987-4039-1-git-send-email-berrange@redhat.com> <1464885987-4039-4-git-send-email-berrange@redhat.com> <87y46e778o.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87y46e778o.fsf@dusky.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH v5 03/11] qom: support arbitrary non-scalar properties with -object List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz , Paolo Bonzini , Andreas =?utf-8?Q?F=C3=A4rber?= On Thu, Jun 09, 2016 at 04:43:35PM +0200, Markus Armbruster wrote: > "Daniel P. Berrange" writes: > > > 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. > > It should be practical to create a new option input visitor that parses > command line syntax straight into a QAPI visit, without the list magic, > and with fewer or no restrictions. Then we could start defining complex > command line arguments as QAPI types, parse them straight into generated > QAPI types, and dispense with the QDict wrangling. Funnily enough I did actually start out trying to implement pretty much exactly that. I found that in my new opts visitor, I was essentially parsing the QemuOpts into QDict/QLists to handle the recursion from the visitor. At this point I was starting to duplicate much code from QDict and QmpInputVisitor, so it abandoned that approach and went for the more general QemuOpts -> QDict crumping instead, since it the goal to be achieved with simpler code overall. 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 :|