[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