On Tue, Aug 19, 2014 at 03:47:20PM +0100, Stefan Hajnoczi wrote: > On Sat, Aug 16, 2014 at 12:23:52AM +0800, Amos Kong wrote: > > This reverts commit 57d3e1b3f52d07d215ed96df946ee01f8d9f9526. > > > > The commit introduced a regression bug, the initialization order of > > virtio-rng > > backend was changed. > > > > # x86_64-softmmu/qemu-system-x86_64 -monitor stdio -vnc :0 \ > > -chardev socket,host=localhost,port=1024,id=chr0 \ > > -object rng-egd,chardev=chr0,id=rng0
Paolo posted a new patch [1] to fix this bug, above commandline works.
> > qemu-system-x86_64: -object rng-egd,chardev=chr0,id=rng0: Device 'chr0'
> > not found
> >
> > Chardev 'chr0' isn't initialized when we try to open rng backend,
>
> More detail:
> The problem is that vl.c:main() calls object_create() on -object before
> -chardev options are processed. Moving the object_create() call after
> chardev is arbitrary and does not work if a chardev depends on an
> -object.
Stefan, can you give an example of the complex relying? So Paolo's patch can't
solve this problem?
> It would have been nice to process command-line options in left-to-right
> order instead of grouping them by option type. I doubt we can change
> this now since it would break the command-line.
>
> > Conflicts:
> > hw/virtio/virtio-rng.c
>
> This shouldn't be here.
>
> I agree with reverting commit 57d3e1b3f52d07d215ed96df946ee01f8d9f9526.
--
Amos.
pgpKSkgMiF8ij.pgp
Description: PGP signature
