From: "Daniel P. Berrange" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] RFC: -object vs -chardev creation order
Date: Wed, 18 Mar 2015 09:59:14 +0000 [thread overview]
Message-ID: <20150318095914.GC3250@redhat.com> (raw)
In-Reply-To: <87vbhyej42.fsf@blackfin.pond.sub.org>
On Wed, Mar 18, 2015 at 10:43:25AM +0100, Markus Armbruster wrote:
> "Daniel P. Berrange" <berrange@redhat.com> 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 :|
prev parent reply other threads:[~2015-03-18 9:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-17 19:08 [Qemu-devel] RFC: -object vs -chardev creation order Daniel P. Berrange
2015-03-18 7:32 ` Paolo Bonzini
2015-03-18 9:43 ` Markus Armbruster
2015-03-18 9:59 ` Daniel P. Berrange [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150318095914.GC3250@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).