On (Wed) 03 Apr 2013 [15:08:40], Anthony Liguori wrote:
> Amit Shah <amit.s...@redhat.com> writes:
>
> > On (Tue) 02 Apr 2013 [07:52:19], Anthony Liguori wrote:
> >> Amit Shah <amit.s...@redhat.com> writes:
> >>
> >> >> > 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.
>
> The fix I posted minus the needed s/EINTR/EAGAIN/g is pretty straight
> forward and IMHO the proper way to handle this.
>
> Is there something you think is broken with it? I guess I should turn
> it into a real patch but I was hoping you would so I didn't have to
> recreate the original problem :-)
Oh yes, I'll do that and test, and will submit a patch. My concern is
just that we'll forget checking for EINTR and fall into these traps
with open-coded read() calls instead of using wrappers.
Amit
