Hi
----- Original Message -----
> Hi
>
> ----- Original Message -----
> > When a serial port writes data to a pty that's disconnected, drop the
> > data and return the length dropped. This avoids triggering pointless
> > retries in callers like the 16550A serial_xmit(), and causes
> > qemu_chr_fe_write() to write all data to the log file, rather than
> > logging only while a pty client like virsh console happens to be
> > connected.
> >
> > Signed-off-by: Ed Swierk <eswi...@skyportsystems.com>
> > ---
> > qemu-char.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/qemu-char.c b/qemu-char.c
> > index 676944a..ccb6923 100644
> > --- a/qemu-char.c
> > +++ b/qemu-char.c
> > @@ -1528,7 +1528,7 @@ static int pty_chr_write(CharDriverState *chr, const
> > uint8_t *buf, int len)
> > /* guest sends data, check for (re-)connect */
> > pty_chr_update_read_handler_locked(chr);
> > if (!s->connected) {
> > - return 0;
> > + return len;
>
> I think this can be confusing if some backends silently drop the data (under
> disconnected state), while other don't. Perhaps we should have instead a new
> common chardev property "hup-drop" ? (suggestions for better name welcome)
>
actually,tcp_chr_write() already drops data on disconnected state, so they
would have different default value for backward compatibility...
> > }
> > }
> > return io_channel_send(s->ioc, buf, len);
> > --
> > 1.9.1
> >
> >
>
