linux-kernel - Re: [PATCH] eventfd, signalfd, timerfd, epoll

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 28 Apr 2008 09:12:20 +0200
From:	"Michael Kerrisk" <mtk.manpages@...il.com>
To:	"Davide Libenzi" <davidel@...ilserver.org>
Cc:	"Ulrich Drepper" <drepper@...hat.com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] eventfd, signalfd, timerfd, epoll_create w/flags

On 4/28/08, Davide Libenzi <davidel@...ilserver.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/