From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39374) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmO2f-0000iG-Tc for qemu-devel@nongnu.org; Wed, 04 Jul 2012 07:46:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmO2c-0006UZ-I0 for qemu-devel@nongnu.org; Wed, 04 Jul 2012 07:46:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43398) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmO2c-0006UM-AG for qemu-devel@nongnu.org; Wed, 04 Jul 2012 07:46:42 -0400 Date: Wed, 4 Jul 2012 17:16:32 +0530 From: Amit Shah Message-ID: <20120704114632.GB11292@amit.redhat.com> References: <1340664362-25603-1-git-send-email-aliguori@us.ibm.com> <201207012306.36639.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201207012306.36639.paul@codesourcery.com> Subject: Re: [Qemu-devel] [RFC PATCH 0/4] virtio-rng and RngBackend infrastructure (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Kevin Wolf , Anthony Liguori , Stefan Hajnoczi , Markus Armbruster , qemu-devel@nongnu.org, Paolo Bonzini , Andreas Faerber 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