On 03/01/2013 02:08 PM, Anthony Liguori wrote: >>> You can pass chardevs to the egd backend. It's really not a good idea >>> to pass a fd via rng-rangom.
Why not? If you are running a single guest, why can't libvirt pass that one guest an fd instead of making qemu open() the file? >> >> Fine, then we won't use fd passing for this device, whatever the reason >> may be. > > So let's step back. There are two backends currently supported: > rng-random and rng-egd. I don't see any point in taking an fd for > rng-random. I don't think labeling comes into play here. > > But if libvirt wants to interact with virtio-rng in a more intelligent > way (implementing a policy to distribute entropy), then rng-egd is the > right way to do that. Yes, libvirt will probably use rng-egd when distributing randomness among multiple guests. But libvirt wants to target BOTH forms of rng, in order to let the user choose which one is best for their needs. If rng-random is not useful to any end user, then why did qemu expose it in the first place? And if qemu thought it was worth exposing, then libvirt thinks it is worth targetting, and by using qemu_open instead of raw open, then fd passing is possible. Policy (whether it makes sense to pass an fd for a random generator, and whether /dev/random or /dev/urandom or something else is best) may be important, but it is orthogonal to the issue that I raised about consistency. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature