From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 05/10] KVM: Adds ability to signal userspace using a file-descriptor Date: Mon, 14 May 2007 20:23:30 +0300 Message-ID: <46489B12.8030807@qumranet.com> References: <20070510123831.10200.4769.stgit@novell1.haskins.net> <20070510124706.10200.68571.stgit@novell1.haskins.net> <46470BF7.5080108@qumranet.com> <46481A61.BA47.005A.0@novell.com> <46485488.2010608@qumranet.com> <4648986B.9090403@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Davide Libenzi Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Davide Libenzi wrote: > On Mon, 14 May 2007, Avi Kivity wrote: > > >> Davide Libenzi wrote: >> >>> On Mon, 14 May 2007, Avi Kivity wrote: >>> >>> >>> >>>> Gregory Haskins wrote: >>>> >>>> >>>>>> Is having a read() (or a write()) actually necessary? >>>>>> >>>>>> >>>>> Based on what I know: yes. It could be a case of ignorance, however ;) >>>>> >>>>> Heres why I think its necessary: You need poll to simply tell you when >>>>> something is pending. You can't clear the pending status in poll >>>>> because >>>>> you cannot predict the internal access pattern (e.g. I assume it could >>>>> be >>>>> polled multiple times by the kernel without returning immediately to >>>>> userspace). Therefore, you need a second method to actually clear the >>>>> pending "signal", which I use the read() method for. I can be convinced >>>>> otherwise, but that was my original thinking. >>>>> >>>>> >>>> I think you are right, but am cc'ing an expert. Davide, we're using an fd >>>> to >>>> signal something to userspace, but have nothing to actually read() or >>>> write(). >>>> Is a read() or write() avoidable? >>>> >>>> >>> I don't know exactly what you want to do, but signalfd signal de-queueing >>> competes with the standard Linux signal delivery, if signals are not >>> blocked. >>> So if you don't want to read() the signal, you can just leave the signal >>> unblocked, and it'll be delivered to the signal handler. >>> You can even leave the signal blocked and avoid read(), but poll() on the >>> signalfd will always return POLLIN if the sigmask includes the pending >>> signal. >>> >>> >> This is not about a real signal. We have an fd (for a pseudo filesystem) >> which wants to indicate its readiness to select(), but which doesn't have any >> real data to produce. Is it possible to implement this without a read() or a >> write()? >> >> We're also looking at using an eventfd for this, so this may be moot. >> > > Do you close the signaled fd after receiving the signal/event? If you > don't close it, eventfd will always return ready (POLLIN). > We don't. Anyway, that's what we thought. Thanks for the confirmation. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/