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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.