Re: [PATCH] eventfd, signalfd, timerfd, epoll_create w/flags

["Michael Kerrisk" <mtk.manpages@gmail.com>]

On 4/28/08, Davide Libenzi <davidel@xmailserver.org> wrote:
> On Sun, 27 Apr 2008, Ulrich Drepper wrote:
>
>  > In the absence of sys_indirect we need the following patches as well.  These
>  > are all the event handling functions: epoll_create, signalfd, timerfd, eventd.
>  >
>  > There is good news and bad.  The good news is that the timerfd interface
>  > already has a flags parameter.  We just have to put it to use.  It's IMO
>  > not a good idea to use the O_* values for any of the flag parameters so I
>  > introduced new macros for all the functions.
>  >
>  > For signalfd and eventfd no flags parameter is available in the syscall.
>  > But for the userlevel interfaces I have added such a parameter back when.
>  > They are just required to be zero so far.  This means the new syscalls
>  > will completely transparently be used once glibc knows about them.
>  > Programs can start using the new flags and get told when the implementation
>  > doesn't support it.
>  >
>  > The bad case is epoll_create.  Neither the kernel nor the userlevel interface
>  > has a flags parameter.  So we need a new, additional interface.  We could have
>  > one which differs from epoll_create only in that it returns a file descriptor
>  > with close-on-exec already set.  I don't like that.  Instead, the patch adds
>  > a new interface with a flags parameter.  More flexibility in future.
>
>
> Ok, I asked this myself for about ten minutes, than I gave up. But why
>  sys_epoll_createp() instead of sys_epoll_create2()? There MUST be a reason
>  to deviate from the standard of all the other ones...
>  The one between sys_indirect and syscall explosion is the battle of the
>  ugly.
>  Besides that, patches look fine to me (though w/out a very good reason, I
>  prefer sys_epoll_create2() instead of sys_epoll_createp()).

This "p" doesn't follow convention.  The "p" that has appeared on some
syscalls is by analogy with pselect().

pselect() = select() + a sigset parama=ter.

I seem to recall that the "p" is because this was a POSIX invention.

Anyway, the "p" has been added to a number of other Linux syscalls
that have likewise added a sigset:

poll() --> ppoll()
epoll_wait() --> epoll_pwait()
and now: accept() --> paccept()

Adding a "p" to the name epoll_create() would be a mistake by this convention.