qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 1/1] rng backend: open backend in blocking mode


From: Amit Shah
Subject: Re: [Qemu-devel] [PATCH 1/1] rng backend: open backend in blocking mode
Date: Wed, 3 Apr 2013 11:58:23 +0530

On (Tue) 02 Apr 2013 [07:52:19], Anthony Liguori wrote:
> Amit Shah <address@hidden> writes:
> 
> > On (Mon) 01 Apr 2013 [09:02:46], Anthony Liguori wrote:
> >> Amit Shah <address@hidden> writes:
> >> 
> >> > Opening backends in non-blocking mode isn't necessary, we don't do
> >> > anything while waiting for data.
> >> >
> >> > This also excuses us from checking for EAGAIN, which for the default
> >> > random backend, is a very common return error type.
> >> 
> >> It's not common...  It really shouldn't happen however.
> >
> > EAGAIN is common when a file is opened in non-blocking mode.  Needs to
> > be made verbose?
> 
> EAGAIN doesn't just happen randomly.  It only happens when you read from
> an fd when no data is present.  Normally, that is something that is
> predictable.

When we open /dev/random as the default backend, we should expect more
EAGAINs than data :-)  i.e. /dev/random blocks, we know it.

> >> > backends/rng-random.c:44:entropy_available: assertion failed: (len != -1)
> >> >
> >> > without this fix.
> >> 
> >> This fix would cause QEMU to block indefinitely which I don't think is
> >> very good behavior.  I think a better solution would be:

How about relegating it to glib functions, and hooking it up so that
/dev/random is polled for data, and this function gets called when
/dev/random has data to give out?  Sure, when a read is attempted,
there might be no data available again, but we could then go back to
polling.


                Amit



reply via email to

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