On (Tue) Mar 23 2010 [11:00:23], Michael S. Tsirkin wrote:
> On Tue, Mar 23, 2010 at 02:28:00PM +0530, Amit Shah wrote:
> > The virtio-serial ports are like pipes, if there's no reader on the
> > other end, sending data might get it either ignored or the host might
> > return '0', which would make guests get -EAGAIN. Since we know the state
> > of the host port connection, it's appropriate to let the application
> > know that the other end isn't connected.
> >
> > Signed-off-by: Amit Shah <[email protected]>
> > ---
> > drivers/char/virtio_console.c | 3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
> > index 55de0b5..4562964 100644
> > --- a/drivers/char/virtio_console.c
> > +++ b/drivers/char/virtio_console.c
> > @@ -411,6 +411,9 @@ static ssize_t send_buf(struct port *port, void
> > *in_buf, size_t in_count)
> > ssize_t ret;
> > unsigned int len;
> >
> > + if (use_multiport(port->portdev) && !port->host_connected)
> > + return -EPIPE;
> > +
>
> Hmm, do applications actually handle this error?
As Michael points out on irc, console-handling apps may not handle EPIPE
properly. So I guess the test should be reworked to:
if (!is_console_port(port) && !port->host_connected)
return -EPIPE;
Also, he points out that write(2) mentions other error messages can be
returned depending on the file type. So we could return -ENOTCONN.
Amit
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization
