On (Sun) 01 Jul 2012 [23:06:36], Paul Brook wrote:
> > This series depends on my QOM -object series that I just posted.
> >
> > In Amit's thread on virtio-rng, danpb mentioned that we really ought to
> > have a proper RNG backend infrastructure and of course he's correct on
> > that.
> >
> > Now that we have QOM, I wanted to demonstrate how we can use QOM to
> > construct a complete backend without adding any new infrastructure.
> >
> > I've now implemented a urandom and egd backend and tested them. I think
> > the first three patches are ready to go.
>
> I never really understood why this exists in the first place. It's a simple
> readonly charcter device. IMHO you should be using virtio-serial. This is
> virtio-console v.s. virtio-serial all over again.
> The only thing close to a reason I've heard is that guest OS is incompetent
> and can't source random rata from a serial device.
Linux has a virtio-rng driver for quite a while; some other hypervisor
implementation may have the corresponding device, I'm not aware of
it. This series just adds a corresponding device to qemu.
You're right that it's just a chardev interface, and virtio-serial
would've been ideal for this, but given Linux has a driver already,
it's best to add the device to qemu.
> Even accepting the pointless guest device, I see absolutely no reason to have
> special infrastructure for this within qemu. Character devices do everything
> you need. Creating annother "read stream of data" API is needless
> duplication
> and only going to reintroduce bugs we already fixed in the character device
> layer.
Well I do agree with this qemu doesn't really need to bother about the
various ways of getting random numbers, just accept them over a
chardev and fwd them to the guest.
Amit
