[RFC PATCH 0/3] epoll: read(),write(),ioctl() interface

[RFC PATCH 0/3] epoll: read(),write(),ioctl() interface

[Nathaniel Yazdani]

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 struct epoll
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.

 Documentation/ioctl/ioctl-number.txt |   1 +
 fs/eventpoll.c                       | 534 ++++++++++++++++++++++++-----------
 include/uapi/linux/eventpoll.h       |  10 +
 3 files changed, 384 insertions(+), 161 deletions(-)

[RFC PATCH 0/3] epoll: read(),write(),ioctl() interface

[Nathaniel Yazdani]

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.

 Documentation/ioctl/ioctl-number.txt |   1 +
 fs/eventpoll.c                       | 534 ++++++++++++++++++++++++-----------
 include/uapi/linux/eventpoll.h       |  10 +
 3 files changed, 384 insertions(+), 161 deletions(-)

Re: [RFC PATCH 0/3] epoll: read(),write(),ioctl() interface

[Clemens Ladisch]

Nathaniel Yazdani wrote:
> Using the normal I/O interface to manipulate eventpolls is much neater
> than using epoll-specific syscalls

But it introduces a _second_ API, which is epoll-specific too, and does
not use the standard semantics either.

> while also allowing for greater flexibility (theoretically, pipes could
> be used to filter access).

I do not understand this.

> read() simply waits for enough events to fill the provided buffer.

The usual semantics of read() are to return a partially filled buffer if
it would block otherwise, i.e., blocking is done only if the returned
buffer would have been empty.

> As timeout control is essential for polling to be practical, ioctl() is
> used to configure an optional timeout

This is what the timeout parameter of poll() and friends is for.


Regards,
Clemens

Re: [RFC PATCH 0/3] epoll: read(),write(),ioctl() interface

[Nathaniel Yazdani]

On 2/3/14, Clemens Ladisch <clemens@ladisch.de> wrote:
> Nathaniel Yazdani wrote:
>> Using the normal I/O interface to manipulate eventpolls is much neater
>> than using epoll-specific syscalls
>
> But it introduces a _second_ API, which is epoll-specific too, and does
> not use the standard semantics either.
>
>> while also allowing for greater flexibility (theoretically, pipes could
>> be used to filter access).
>
> I do not understand this.

The idea here was that if epoll is controlled by read()/write(), then
a program could be written so that it expects the epoll to dup()ed
to a second file descriptor, using one exclusively for writing & the
other exclusively for reading. That way, if an application is in
debug mode, for example, it could start up a thread to replace
those two file descriptors with pipes, so that thread would then
be able to tee, preprocess, or do whatever else to the epoll
streams.

>> read() simply waits for enough events to fill the provided buffer.
>
> The usual semantics of read() are to return a partially filled buffer if
> it would block otherwise, i.e., blocking is done only if the returned
> buffer would have been empty.
>
>> As timeout control is essential for polling to be practical, ioctl() is
>> used to configure an optional timeout
>
> This is what the timeout parameter of poll() and friends is for.

I admit that part of this approach isn't the best.

Either way I appreciate your feedback,
Nathaniel Yazdani

Re: [RFC PATCH 0/3] epoll: read(),write(),ioctl() interface

[Andy Lutomirski]

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

> 
>  Documentation/ioctl/ioctl-number.txt |   1 +
>  fs/eventpoll.c                       | 534 ++++++++++++++++++++++++-----------
>  include/uapi/linux/eventpoll.h       |  10 +
>  3 files changed, 384 insertions(+), 161 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC PATCH 0/3] epoll: read(),write(),ioctl() interface

[Nathaniel Yazdani]

On 2/3/14, Andy Lutomirski <luto@amacapital.net> 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

Re: [RFC PATCH 0/3] epoll: read(),write(),ioctl() interface

[Andy Lutomirski]

On Mon, Feb 3, 2014 at 11:42 AM, Nathaniel Yazdani
<n1ght.4nd.d4y@gmail.com> wrote:
> On 2/3/14, Andy Lutomirski <luto@amacapital.net> 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 :)

If by "sought after", you mean "is there at least one epoll user who
wants them", then yes :)

I think that EPOLLET and EPOLLONESHOT are giant hacks, and that what
everyone really wants is the ability to very efficiently toggle events
on and off.  The ability to do it simultaneously and inexpensively
with epoll_wait would make it happen.

--Andy

>
> Thanks for your input,
> Nate Yazdani



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [RFC PATCH 0/3] epoll: read(),write(),ioctl() interface

[Eric Wong]

Andy Lutomirski <luto@amacapital.net> wrote:
> >> On 02/02/2014 06:17 PM, Nathaniel Yazdani wrote:
> > 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 :)
> 
> If by "sought after", you mean "is there at least one epoll user who
> wants them", then yes :)
> 
> I think that EPOLLET and EPOLLONESHOT are giant hacks, and that what
> everyone really wants is the ability to very efficiently toggle events
> on and off.  The ability to do it simultaneously and inexpensively
> with epoll_wait would make it happen.

Everybody using single-threaded epoll, you mean?  I suppose there's
quite a few of those.

I've pondered an epoll_xchg syscall which would behave like *BSD kevent
to satisfy single-threaded users, but never got around to it.  All my
epoll uses are multithreaded w/ oneshot nowadays, so xchg would only
save one syscall per thread.

Re: [RFC PATCH 0/3] epoll: read(),write(),ioctl() interface

[Andy Lutomirski]

On Mon, Feb 3, 2014 at 1:51 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Andy Lutomirski <luto@amacapital.net> wrote:
>> >> On 02/02/2014 06:17 PM, Nathaniel Yazdani wrote:
>> > 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 :)
>>
>> If by "sought after", you mean "is there at least one epoll user who
>> wants them", then yes :)
>>
>> I think that EPOLLET and EPOLLONESHOT are giant hacks, and that what
>> everyone really wants is the ability to very efficiently toggle events
>> on and off.  The ability to do it simultaneously and inexpensively
>> with epoll_wait would make it happen.
>
> Everybody using single-threaded epoll, you mean?  I suppose there's
> quite a few of those.
>
> I've pondered an epoll_xchg syscall which would behave like *BSD kevent
> to satisfy single-threaded users, but never got around to it.  All my
> epoll uses are multithreaded w/ oneshot nowadays, so xchg would only
> save one syscall per thread.

Even for multithreaded, the ability to rearm EPOLLONESHOT entries
without extra syscalls would probably be useful.

--Andy