[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 0/4] virtio-rng and RngBackend infrastructur

From: Amit Shah
Subject: Re: [Qemu-devel] [RFC PATCH 0/4] virtio-rng and RngBackend infrastructure (v2)
Date: Wed, 4 Jul 2012 17:16:32 +0530

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]