[Qemu-devel] RFC: -object vs -chardev creation order

["Daniel P. Berrange" <berrange@redhat.com>]

The current QEMU startup code will create -chardev backends first, then
create -object backends, then -fsdev backends and so on, in some pretty
arbitrary order of types.

There is already a dependancy from the rng-egd object type, which has a
link to a chardev, which requires -chardev options be processed before
-object options.

In my work to introduce an object type for TLS credentials though, we
encounter exactly the opposite dependancy. A -chardev option will
require that -object options be processed first, so that the TLS
credantials can be created.

This is a no-win situation. Both orders of creation are wrong for some
set of use cases. This is only going to get worse over time, as more
types of user creatable objects are defined.

The application invoking QEMU could easily solve it, by putting the
args on the command line in the order in which they need to processed,
but then QEMU throws away this ordering information and creates them
based on type of backend.

I'm unclear on whether anyone has thought about ways to solve this yet,
but it is a blocker for my work now, so I need to figure out some kind
of solution asap, even if only a temporary workaround.

One option is to convert the -chardev backends so they become user
creatable objects, and thus -object can obsolete use of -chardev
for these. This sounds simple, but I fear it could be a rather large
yak shaving exercise to get that done.

Another idea is to perhaps change the way options are stored, so that
instead of having a separate QemuOptsList for each type of option, have
one single list and store the type with each entry in the list. Then we
can iterate over the single list creating things in exactly the same
order that they were passed on the command line.  I fear this may cause
regressions for apps using QEMU though - eg if some app is placing
'-object rng-egd' in the args, before the -chardev it would currently
work, but if we switch to honour ordering it would fail. We could
introduce a flag -strict-ordering but that feels gross in itself.

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....

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 :|