From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYAl2-0008MR-ER for qemu-devel@nongnu.org; Wed, 18 Mar 2015 05:59:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYAky-0005LD-1C for qemu-devel@nongnu.org; Wed, 18 Mar 2015 05:59:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52056) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYAkx-0005Kq-Ox for qemu-devel@nongnu.org; Wed, 18 Mar 2015 05:59:19 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2I9xIVv022791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 18 Mar 2015 05:59:18 -0400 Date: Wed, 18 Mar 2015 09:59:14 +0000 From: "Daniel P. Berrange" Message-ID: <20150318095914.GC3250@redhat.com> References: <20150317190836.GP6540@redhat.com> <87vbhyej42.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87vbhyej42.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] RFC: -object vs -chardev creation order Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org On Wed, Mar 18, 2015 at 10:43:25AM +0100, Markus Armbruster wrote: > "Daniel P. Berrange" writes: > > A third option is to not process -object args in one go, instead process > > each type of object at a time. eg we'd first create all the > > -object tls-credential instances, then create the -chardev instances, > > then create the -object rng-egd instances. This is probably the least > > amount of work in short term, but not all that scalable, unless we do > > a catch-all default case, so we only need code up hacks for a few > > particular object types. > > > > Thus my gut feeling is to do option 3, but I'd like other opinions before > > embarking on this.... > > Piling yet another hack on top isn't great, put telling you "no more > hacks" after everybody and his dog already got to pile on some doesn't > feel fair. I think I'll do this right now, since it should be a fast fix. > That said: can we sort the creation work topologically? Requires > identifying references. In the QemuOpts world, a reference is a > string-valued parameter that is interpreted as ID in a well-known > QemuOptsList. Adding the necessary information to QemuOptDesc desc[] > shouldn't be too hard. The ones with empty desc[] could be troublesome, > as usual. This sounds intriguing though - we should have enough info around to do a topological sort - its a shame that properties are only registered at time the object is created, rather than being registered against the classes, as then we wouldn't even need to add more info to the QemuOptsList. I'll have a think about this approach though and see if I can come up with something that works 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 :|