On 2/3/14, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On 02/02/2014 06:17 PM, Nathaniel Yazdani wrote: >> Hi everyone, >> >> This patch series adds support for read(), write(), and ioctl() >> operations >> on eventpolls as well as an associated userspace structure to format the >> eventpoll entries delivered via read()/write() buffers. The new >> structure, >> struct epoll, differs from struct epoll_event mainly in that it also >> holds >> the associated file descriptor. Using the normal I/O interface to >> manipulate >> eventpolls is much neater than using epoll-specific syscalls while also >> allowing for greater flexibility (theoretically, pipes could be used to >> filter access). Specifically, write() creates, modifies, and/or removes >> event >> entries stored in the supplied buffer, using the userspace identifier to >> check whether an entry exists and removing it if no events are set to >> trigger >> it, while read() simply waits for enough events to fill the provided >> buffer. >> As timeout control is essential for polling to be practical, ioctl() is >> used >> to configure an optional timeout, which is infinite by default. > > If major changes are made to the epoll API, I want a way to do a bunch > of EPOLL_CTL_MODs and a wait, all in one syscall. Even better: allow > more flexible timeouts (CLOCK_MONOTONIC, CLOCK_REALTIME, etc) at the > same time. > > Since this can't do that, I'm not terribly inspired. > > --Andy So are you saying that those features you mentioned are specifically sought after for the kernel? If so I'd like to take a crack at some of them, may as well get some use out of my new knowledge of epoll internals :) Thanks for your input, Nate Yazdani -- 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
