On (Tue) 22 Feb 2011 [16:40:55], Michael Roth wrote:
> If something in the guest is attempting to read/write from the
> virtio-serial device, and nothing is connected to virtio-serial's
> host character device (say, a socket)
>
> 1. writes will block until something connect()s, at which point the
> write will succeed
>
> 2. reads will always return 0 until something connect()s, at which
> point the reads will block until there's data
>
> This makes it difficult (impossible?) to implement the notion of
> connect/disconnect or open/close over virtio-serial without layering
> another protocol on top using hackish things like length-encoded
> payloads or sentinel values to determine the end of one
> RPC/request/response/session and the start of the next.
>
> For instance, if the host side disconnects, then reconnects before
> we read(), we may never get the read()=0, and our FD remains valid.
> Whereas with a tcp/unix socket our FD is no longer valid, and the
> read()=0 is an event we can check for at any point after the other
> end does a close/disconnect.
There's SIGIO support, so host connect-disconnect notifications can be
caught via the signal.
Also, nonblocking reads/writes will return -EPIPE if the host-side
connection is not up.
Amit
