Messages in this thread | | | Date | Mon, 28 Apr 2008 09:12:20 +0200 | From | "Michael Kerrisk" <> | Subject | Re: [PATCH] eventfd, signalfd, timerfd, epoll_create w/flags |
| |
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.
| |