From: Gerd Hoffmann <kraxel@redhat.com>
To: Ian Molton <ian.molton@collabora.co.uk>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] virtio-rng
Date: Mon, 16 Nov 2009 14:10:05 +0100 [thread overview]
Message-ID: <4B014F2D.3040205@redhat.com> (raw)
In-Reply-To: <4B014584.6000001@collabora.co.uk>
On 11/16/09 13:28, Ian Molton wrote:
> I've done something similar (below)
>
> My commandline looks like:
>
> - -virtiorng dev=/dev/foo,rate=1234
>
> I added some properties to my driver which are obviously then filled in
> from the options code, and I do my init like this:
There is no need for a new -virtiorng switch. qdev allows to set any
property when creating devices via -device on the command line.
> VirtIODevice *virtio_rng_init(DeviceState *dev, RNGConf *rngdev)
> {
> VirtIORng *s;
> s = (VirtIORng *)virtio_common_init("virtio-rng",
> VIRTIO_ID_RNG,
> 0, sizeof(VirtIORng));
>
> if (!s)
> return NULL;
>
> s->vdev.get_features = virtio_rng_get_features;
>
> s->vq = virtio_add_queue(&s->vdev, 128, virtio_rng_handle);
> s->chr = qemu_chr_open("vrngdev", rngdev->device, NULL);
>
> ...
>
> return&s->vdev;
> }
>
> Is this 'not the right way' ? I think the commandline looks much simpler
> this way.
The point is to separate host and guest state. -chardev ist host state,
the device is guest state, and they are linked using the chardev name.
> OTOH, I can see that this might help with my next problem, which is that
> I want to write EGD support for virtio-rng, so I'm guessing my
> commandline would (in your scheme) need to be something like:
>
>
> -tcpsocketthing $addr.of.egd.server,id=some-name-here,
> more-egd-client-options
> -device virtio-rng,tcpsocketthing=some-name-here,rate=$limit
Maybe ...
-chardev socket,id=egd,host=egd.domain.tld,port=whatever
-device virtio-rng,chardev=egd
... ?
> This doesnt, however, get around my problem that the -device option
> doesnt know how to parse OPT_SIZE types, though. (I'd like to be able to
> specify 'rate' in B/s or KB/s (or even kbits/sec, more appropriately))
Yes, there is no qdev property type (yet) which can parse those
postfixes. Which is no reason to not add one though ;)
cheers,
Gerd
next prev parent reply other threads:[~2009-11-16 13:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-11 21:31 [Qemu-devel] virtio-rng Ian Molton
2009-11-11 22:57 ` Paul Brook
2009-11-16 9:45 ` Gerd Hoffmann
2009-11-16 12:28 ` Ian Molton
2009-11-16 13:10 ` Gerd Hoffmann [this message]
2009-11-16 17:58 ` Ian Molton
2009-11-16 22:51 ` Jamie Lokier
2009-11-16 23:16 ` Ian Molton
2009-11-16 23:35 ` Jamie Lokier
2009-11-17 9:18 ` Ian Molton
2009-11-17 9:24 ` Amit Shah
[not found] ` <4B02705A.5060400@collabora.co.uk>
[not found] ` <20091117095456.GA11125@amit-x200.redhat.com>
[not found] ` <4B0278B0.1080505@collabora.co.uk>
[not found] ` <20091117102837.GA11493@amit-x200.redhat.com>
2009-11-17 11:10 ` Ian Molton
2009-11-17 11:25 ` Amit Shah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B014F2D.3040205@redhat.com \
--to=kraxel@redhat.com \
--cc=ian.molton@collabora.co.uk \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).