lkml.org 
[lkml]   [2008]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.


\
 
 \ /
  Last update: 2008-04-28 09:15    [W:0.206 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site