From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1947183Ab3BHWIT (ORCPT ); Fri, 8 Feb 2013 17:08:19 -0500 Received: from dcvr.yhbt.net ([64.71.152.64]:55460 "EHLO dcvr.yhbt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1947025Ab3BHWIR (ORCPT ); Fri, 8 Feb 2013 17:08:17 -0500 Date: Fri, 8 Feb 2013 22:08:17 +0000 From: Eric Wong To: Andy Lutomirski Cc: Martin Sustrik , Alexander Viro , Andrew Morton , Sha Zhengju , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] eventfd: implementation of EFD_MASK flag Message-ID: <20130208220817.GA4256@dcvr.yhbt.net> References: <1360219292-19754-1-git-send-email-sustrik@250bpm.com> <5113FCA7.4020207@mit.edu> <51140A60.4070705@250bpm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andy Lutomirski wrote: > On Thu, Feb 7, 2013 at 12:11 PM, Martin Sustrik wrote: > > On 07/02/13 20:12, Andy Lutomirski wrote: > >> On 02/06/2013 10:41 PM, Martin Sustrik wrote: > >>> The value of 'events' should be any combination of event flags as defined > >>> by > >>> poll(2) function (POLLIN, POLLOUT, POLLERR, POLLHUP etc.) Specified > >>> events will > >>> be signaled when polling (select, poll, epoll) on the eventfd is done > >>> later on. > >>> 'ptr' is an opaque pointer that is not interpreted by eventfd object. > >> > >> How does this interact with EPOLLET? > > > > That's an interesting question. The original eventfd code doesn't do > > anything specific to either edge or level mode. Neither does my patch. > > > > Inspection of the code seems to suggest that edge vs. level distinction is > > handled elsewhere (ep_send_events_proc) where there is a separate list of > > ready events and the function, after returning the event, decides whether to > > leave the event in the list (level) or delete it from the list (edge). Right, the edge vs. level distinction is internal to epoll. > Hmm. Having looked at the eventpoll.c source again, I remain > unconvinced that EPOLLET works the way that any userspace developer > would expect it to. As as userspace developer, EPOLLET seems to work as expected/documented; but I realized EPOLLONESHOT is what I want to be using instead. > > In any case, review from someone with experience with epoll implementation > > would help. I'm no expert, but I don't think eventfd (or any file type) needs to care about what I/O notification scheme/options it's used with.