From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 05/24] compatfd is included before, and it is compiled unconditionally Date: Thu, 01 Oct 2009 09:23:10 -0500 Message-ID: <4AC4BB4E.2000906@codemonkey.ws> References: <6e46fe952ba8d1896e3cab5b24232828d3f827a9.1253272938.git.quintela@redhat.com> <20090922131901.GA22109@infradead.org> <20090922133438.GA12443@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , kvm@vger.kernel.org To: Juan Quintela Return-path: Received: from mail-pz0-f177.google.com ([209.85.222.177]:51199 "EHLO mail-pz0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932683AbZJAO26 (ORCPT ); Thu, 1 Oct 2009 10:28:58 -0400 Received: by pzk7 with SMTP id 7so84487pzk.33 for ; Thu, 01 Oct 2009 07:29:02 -0700 (PDT) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Juan Quintela wrote: > Discused with Anthony about it. signalfd is complicated for qemu > upstream (too difficult to use properly), It's not an issue of being difficult. To emulate signalfd, we need to create a thread that writes to a pipe from a signal handler. The problem is that a write() can return a partial result and following the partial result, we can end up getting an EAGAIN. We have no way to queue signals beyond that point and we have no sane way to deal with partial writes. Instead, how we do this in upstream QEMU is that we install a signal handler and write one byte to the fd. If we get EAGAIN, that's fine because all we care about is that at least one byte exists in the fd's buffer. This requires that we use an fd-per-signal which means we end up with a different model than signalfd. The reason to use signalfd over what we do in upstream QEMU is that signalfd can allow us to mask the signals which means less EINTRs. I don't think that's a huge advantage and the inability to do backwards compatibility in a sane way means that emulated signalfd is not workable. We could possibly introduce a higher level interface that only required one fd per signal and that had a function that drained the signals from the fd without returning any special information. The same is generally true for eventfd. Regards, Anthony Liguori