On Wed, Mar 27, 2013 at 12:07 AM, Stefan Hajnoczi stefa...@redhat.com wrote:
There are several places where QEMU accidentally relies on the O_NONBLOCK
state
of passed file descriptors. Exposing O_NONBLOCK state makes it part of the
QMP
If in future, we push more backend on their dedicated
On Wed, Mar 27, 2013 at 04:37:52PM +0800, liu ping fan wrote:
On Wed, Mar 27, 2013 at 12:07 AM, Stefan Hajnoczi stefa...@redhat.com wrote:
There are several places where QEMU accidentally relies on the O_NONBLOCK
state
of passed file descriptors. Exposing O_NONBLOCK state makes it part of
Stefan Hajnoczi stefa...@redhat.com wrote:
On Wed, Mar 27, 2013 at 04:37:52PM +0800, liu ping fan wrote:
On Wed, Mar 27, 2013 at 12:07 AM, Stefan Hajnoczi stefa...@redhat.com
wrote:
There are several places where QEMU accidentally relies on the
O_NONBLOCK state
of passed file
On Wed, Mar 27, 2013 at 02:06:36PM +0100, Juan Quintela wrote:
Stefan Hajnoczi stefa...@redhat.com wrote:
On Wed, Mar 27, 2013 at 04:37:52PM +0800, liu ping fan wrote:
On Wed, Mar 27, 2013 at 12:07 AM, Stefan Hajnoczi stefa...@redhat.com
wrote:
There are several places where QEMU
There are several places where QEMU accidentally relies on the O_NONBLOCK state
of passed file descriptors. Exposing O_NONBLOCK state makes it part of the QMP
API whenever getfd or fdset_add_fd are used!
Whether or not QEMU will use O_NONBLOCK is an implementation detail and should
be hidden
