Messages in this thread | | | From | Willem de Bruijn <> | Date | Tue, 8 Nov 2022 17:44:58 -0500 | Subject | Re: [PATCH 6/6] eventpoll: add support for min-wait |
| |
On Tue, Nov 8, 2022 at 5:30 PM Jens Axboe <axboe@kernel.dk> wrote: > > On 11/8/22 3:25 PM, Willem de Bruijn wrote: > >>> This would be similar to the approach that willemb@google.com used > >>> when introducing epoll_pwait2. > >> > >> I have, see other replies in this thread, notably the ones with Stefan > >> today. Happy to do that, and my current branch does split out the ctl > >> addition from the meat of the min_wait support for this reason. Can't > >> seem to find a great way to do it, as we'd need to move to a struct > >> argument for this as epoll_pwait2() is already at max arguments for a > >> syscall. Suggestions more than welcome. > > > > Expect an array of two timespecs as fourth argument? > > Unfortunately even epoll_pwait2() doesn't have any kind of flags > argument to be able to do tricks like that... But I guess we could do > that with epoll_pwait3(), but it'd be an extra indirection for the copy > at that point (copy array of pointers, copy pointer if not NULL), which > would be unfortunate. I'd hate to have to argue that API to anyone, let > alone Linus, when pushing the series.
I did mean for a new syscall epoll_pwait3. But not an array of pointers, an array of structs. The second arg is then mandatory for this epoll_pwait_minwait variant of the syscall.
It would indeed have been nicer to be able to do this in epoll_pwait2 based on a flag. It's just doubling the size in copy_from_user in get_timespec64.
Btw, when I added epoll_pwait2, there was a reasonable request to also update the manpages and add a basic test to tools/testing/selftests/filesystems/epoll. That is some extra work with a syscall based approach.
| |