Re: [Qemu-devel] Device initialisation problem: partially solved.

[Ian Molton <ian.molton@collabora.co.uk>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Further investigation seems to have highlighted the problem:

My code is correctly decoding the OPT_SIZE parameter into the
'value.uint' field in a QemuOpt

I've also got the devices properties set up, so that the device may
receive its data.

Eg.

in vl.c

static int virtio_rng_parse(const char *arg)
{
        QemuOpts *opts;

    if (strcmp(arg, "none") == 0) {
        return 0;
    }
    if (!strncmp(arg, "dev", 3)) {
        /* have params -> parse them */
        opts = qemu_opts_parse(&qemu_rng_opts, arg, NULL);
        if (!opts)
            return  -1;
    } else {
        /* create empty opts */
        opts = qemu_opts_create(&qemu_rng_opts, NULL, 0);
    }

    qemu_opt_set(opts, "driver", "virtio-rng-pci");

    return 0;
}

and in hw/virtio.c I have:

,{
        .qdev.name = "virtio-rng-pci",
        .qdev.size = sizeof(VirtIOPCIProxy),
        .init      = virtio_rng_init_pci,
        .exit      = virtio_exit_pci,
        .qdev.props = (Property[]) {
            DEFINE_RNG_PROPERTIES(VirtIOPCIProxy, rng),
            DEFINE_PROP_END_OF_LIST(),
        },
        .qdev.reset = virtio_pci_reset,
    }

Where DEFINE_RNG_PROPERTIES is defined as:

#define DEFINE_RNG_PROPERTIES(_state, _conf)                            \
    DEFINE_PROP_STRING("dev",   _state, _conf.device), \
    DEFINE_PROP_UINT32("rate",   _state, _conf.rate, 0)

So as you can see, I was expecting the rate property to be decoded as an
OPT_SIZE type and that value to be fed into conf.rate

This doesn't happen because in hw/qemu.c we have:

qemu_opt_foreach(opts, set_property, qdev, 1)

Which is doing:

QTAILQ_FOREACH(opt, &opts->head, next) {
        rc = func(opt->name, ******opt->str******, opaque);

IOW, its not passing the nicely decoded OPT_SIZE, but the original
string value.

I cant see a 'nice' solution to this right now, the choices being to
either reimplement the OPT_SIZE parser as a property parser, which seems
horribly inefficient, or to create a new property parser that does a
nasty hack on the offset of opt->str in order to access opt->value.uint,
which seems horribly evil.

Am I missing something here? It seems there is some confusion as to
wether the property code should do the parsing or the options code. Or
both - but then we need some way to tell the properties code to use the
pre-parsed data in circumstances like mine.

Either that or I'm too tired and should go to bed...

- -Ian




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJK/gn4AAoJEFIjE1w7L6YHRw4QAJIkm756yClRneGJY18qH3QH
k5cFR3EaRjC/Q3eKGQ7TeX3HA/KCjpVbyTLxjjqFenVGApMCIAWbVWwjXe3YvI7t
IAG1WOACJTtb3h2uNTf3LFFs3ca6YRy0jhe/pAxoIOZfl6J76PNISa3ly/2+W+2D
OXgoT2mIqDTOtAEMDp3V6JPec+Qz0tAIRsEDuT94ZsRKJCQxvOPyXtreAJMaAAZn
6P0tEzC5gSKKDM5P5p8yT+ZrUgWGNC7iKUJ7t1nHuPV6a/7GezW9whWOPokfn1LG
V3Yil0mdPzbwW/UD+HtDS1mgsvGRDu12q6UhDe/kJp+Mr+Oripq3/UwkqP5tKpAl
MfrJjjT06Q6YwyKvYi3PUYIZeTdtF8VuoHHJA1XEhuQrIrje7jFVMTDy4S6b3Nq4
SvK+x2ni12z5ojUpInWw9ZP4wUFoMzFdGQ7PBoQhN1oTsC1m3NfdL+UUw4wSuLw/
mK93oQz4y9GaFDrajtPL7TFbbyb5PIBmZWq27M5EjEPFMXxZaACQPsXGz16RJRrA
Ck8T+eCDEJ4eOnBN2HDObx1IkQoXJ7K/mGzYj+sPZWhoGpCkDbBLmjL4dtrYUWaa
ae40GymfnkzGmXlRdPjgEXr3CXuTAWaTiqyxWXGMmv90elgyN9wE/o9lajqaO6Ha
LVkIKNHGfYvBpFoAZRZP
=Eeqz
-----END PGP SIGNATURE-----