From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N97b3-00048L-1M for qemu-devel@nongnu.org; Fri, 13 Nov 2009 20:38:37 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N97b1-000481-Uh for qemu-devel@nongnu.org; Fri, 13 Nov 2009 20:38:36 -0500 Received: from [199.232.76.173] (port=36829 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N97b1-00047y-Ob for qemu-devel@nongnu.org; Fri, 13 Nov 2009 20:38:35 -0500 Received: from bhuna.collabora.co.uk ([93.93.128.226]:60515) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N97b1-00023i-6t for qemu-devel@nongnu.org; Fri, 13 Nov 2009 20:38:35 -0500 Received: from [192.168.1.64] (94-192-117-31.zone6.bethere.co.uk [94.192.117.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 8BB1160004D for ; Sat, 14 Nov 2009 01:38:33 +0000 (GMT) Message-ID: <4AFE09FD.800@collabora.co.uk> Date: Sat, 14 Nov 2009 01:38:05 +0000 From: Ian Molton MIME-Version: 1.0 Subject: Re: [Qemu-devel] Device initialisation problem: partially solved. References: <4AFDA5D6.6090306@collabora.co.uk> In-Reply-To: <4AFDA5D6.6090306@collabora.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org -----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-----