On 12/29/14 04:59, Michael Tokarev wrote: > 22.12.2014 18:04, Don Slutz wrote: > >> --- a/qemu-char.c >> +++ b/qemu-char.c >> @@ -1387,6 +1387,7 @@ static CharDriverState *qemu_chr_open_pty(const char >> *id, >> } >> >> close(slave_fd); >> + qemu_set_nonblock(master_fd); >> >> chr = qemu_chr_alloc(); > > > Hm. I'm not sure at all this is a trivial change. While the > patch itself is trivial indeed, it changes behavour of the file > descriptor significantly. Are all the places where this fd is > subsequently used prepared for it being non-blocking? Oh well... ;)
I was not sure on this being trivial also, but it looked like it could be to me. The uses of this FD all looked that they handle non-blocking. Here are the calls to qemu_set_nonblock in qemu-char.c (including this add) : b qemu-char.c qemu_chr_open_fd 1070 qemu_set_nonblock(fd_out); c qemu-char.c qemu_chr_open_stdio 1166 qemu_set_nonblock(0); d qemu-char.c qemu_chr_open_pty 1390 qemu_set_nonblock(master_fd); e qemu-char.c tcp_chr_add_client 2952 qemu_set_nonblock(fd); f qemu-char.c qmp_chardev_open_serial 4060 qemu_set_nonblock(fd); g qemu-char.c qmp_chardev_open_socket 4172 qemu_set_nonblock(s->listen_fd); So there are many cases where the FD is non-blocking already. Hope this info helps. > > Thanks, > > /mjt >
