From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Upk0G-00015n-Al for qemu-devel@nongnu.org; Thu, 20 Jun 2013 14:54:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Upk0D-0002kW-Ro for qemu-devel@nongnu.org; Thu, 20 Jun 2013 14:54:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11587) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Upk0D-0002kI-Iz for qemu-devel@nongnu.org; Thu, 20 Jun 2013 14:54:37 -0400 Message-ID: <51C35048.4040708@redhat.com> Date: Thu, 20 Jun 2013 20:56:08 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <51C19365.5050606@redhat.com> <20130620133003.GA3347@amit-x200.redhat.com> In-Reply-To: <20130620133003.GA3347@amit-x200.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu-ga behavior on virtio-serial unplug List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah , Michael Roth Cc: "qemu-devel@nongnu.org" On 06/20/13 15:31, Amit Shah wrote: > On (Wed) 19 Jun 2013 [13:17:57], Laszlo Ersek wrote: >> In any case we'd need a way to tell "host side close" from "port unplug". > > Will POLLHUP|POLLERR help, along with error returns on read() and > write()? I think so: - read() == 0 --> host side disconnected, - read() == -1, equivalently POLLERR --> unplug (or other error) - write() == -1 / errno == EPIPE: host side disconnected, - write() == -1 / errno == EIO (or ENXIO or EINVAL): unplug I think the current code could be adapted to such a scheme gracefully. (Regarding the error codes on write(), I just made them up, but you get the idea.) On hot-unplug we could bail out to a more external loop that tries to reopen the same device, or just exit and leave the restart to udev/systemd. If possible I would like to avoid SIGIO. SIGIO is basically a non-queued (= can be pending or not pending; any realtime queueing variant is limited in depth hence useless) and edge triggered readiness notification. It isn't portable and requires extra hoops to jump through just to get the file descriptor and to tell a read event from a write event. Although it's possible to base level triggered readiness on top of it (by setting read & write readiness booleans on SIGIO and clearing them on the respective -1/EAGAIN, while blocking SIGIO carefully), I think that's quite distant from our current event loop. Hence we should remove O_ASYNC (and the Solaris equivalent too) with the same fell swoop. Thanks Laszlo