Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Thu, Feb 7, 2013 at 12:11 PM, Martin Sustrik <sustrik@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
