On (Thu) 24 Feb 2011 [08:44:07], Anthony Liguori wrote:
> >>>>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.
> >>I recall looking into this at some point....but don't we get a SIGIO
> >>for read/write-ability in general?
> >I don't get you -- the virtio_console driver emits the SIGIO signal
> >only when the host side connects or disconnects. See
>
> Um, that's not the expected semantics of SIGIO. SIGIO can be
> delivered for any number of reasons (including on a normal file
> descriptor) so if there's no way to poll for the specific event then
> the mechanism is inherently racy.
Well -- for a custom driver something's going to be non-standard: if
it's baking in connection info into the open/close semantics or having
SIGIO delivered when needed.
However, I think a generic library needs to be used for guest-host
communications, abstracting away virtio-serial entirely. This way,
apps should just communicate over tcp, the library should do the
necessary virtio-serial (or even virt-9pfs) calls. This way, all
guest apps written will be infrastructure-agnostic, and if there's a
better protocol to communicate with, virtio-serial can easily be
dropped w/o modifications to apps.
Amit
