[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Device initialisation problem: partially solved.
From: |
Ian Molton |
Subject: |
Re: [Qemu-devel] Device initialisation problem: partially solved. |
Date: |
Sat, 14 Nov 2009 01:38:05 +0000 |
User-agent: |
Mozilla-Thunderbird 2.0.0.22 (X11/20090707) |
-----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-----