From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34957 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pu26d-0002Yk-V1 for qemu-devel@nongnu.org; Mon, 28 Feb 2011 07:21:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pu26c-0002s8-Oc for qemu-devel@nongnu.org; Mon, 28 Feb 2011 07:21:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59852) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pu26c-0002s4-DU for qemu-devel@nongnu.org; Mon, 28 Feb 2011 07:21:38 -0500 Date: Mon, 28 Feb 2011 17:51:32 +0530 From: Amit Shah Message-ID: <20110228122132.GA3116@amit-x200.redhat.com> References: <4D643B77.60109@linux.vnet.ibm.com> <20110223045944.GA9886@amit-x200.redhat.com> <4D651A58.6060606@linux.vnet.ibm.com> <20110224124824.GG8034@amit-x200.redhat.com> <4D666EB7.50802@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D666EB7.50802@linux.vnet.ibm.com> Subject: [Qemu-devel] Re: virtio-serial semantics for binary data and guest agents List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Adam Litke , Michael Roth , "qemu-devel@nongnu.org Developers" 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