11.12.2015 14:29, Ashley Jonathan wrote: > I have experienced a minor difficulty using QEMU with the "-serial pty" > option: > > If a process opens the slave pts device, writes data to it, then immediately > closes it, the data doesn't reliably get delivered to the emulated serial > port. This seems to be because a read of the master pty device returns EIO on > Linux if no process has the pts device open, even when data is waiting "in > the pipe". > > A fix seems to be for QEMU to keep the pts file descriptor open until the pty > is closed, as per the below patch.
The patch looks fine, so Reviewed-by: Michael Tokarev <m...@tls.msk.ru> but I'd love to have an ACK from the maintainer about this one, or for it to pick it up. Thanks, /mjt > --- > qemu-char.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/qemu-char.c b/qemu-char.c > index 2969c44..ed03ba0 100644 > --- a/qemu-char.c > +++ b/qemu-char.c > @@ -1198,6 +1198,7 @@ typedef struct { > int connected; > guint timer_tag; > guint open_tag; > + int slave_fd; > } PtyCharDriver; > > static void pty_chr_update_read_handler_locked(CharDriverState *chr); > @@ -1373,6 +1374,7 @@ static void pty_chr_close(struct CharDriverState *chr) > > qemu_mutex_lock(&chr->chr_write_lock); > pty_chr_state(chr, 0); > + close(s->slave_fd); > fd = g_io_channel_unix_get_fd(s->fd); > g_io_channel_unref(s->fd); > close(fd); > @@ -1401,7 +1403,6 @@ static CharDriverState *qemu_chr_open_pty(const char > *id, > return NULL; > } > > - close(slave_fd); > qemu_set_nonblock(master_fd); > > chr = qemu_chr_alloc(); > @@ -1422,6 +1423,7 @@ static CharDriverState *qemu_chr_open_pty(const char > *id, > chr->explicit_be_open = true; > > s->fd = io_channel_from_fd(master_fd); > + s->slave_fd = slave_fd; > s->timer_tag = 0; > > return chr; >