From: "Michael Kerrisk" <mtk.manpages@gmail.com>
To: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
Cc: "Ulrich Drepper" <drepper@redhat.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
akpm@linux-foundation.org,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Michael Kerrisk" <mtk.manpages@gmail.com>,
michael.kerrisk@gmail.com, linux-man@vger.kernel.org
Subject: Re: [PATCH] alternative to sys_indirect, part 1
Date: Thu, 24 Apr 2008 14:34:27 +0200 [thread overview]
Message-ID: <517f3f820804240534r3bbbdc52s52a6dfe3f2d14b7f@mail.gmail.com> (raw)
In-Reply-To: <20080424112514.055d8071@the-village.bc.nu>
On 4/24/08, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > - I decided against using the O_* flags here. Most are not useful and
> > we might need the bits for something else at some time. Hence the
> > new SOCKFL_* flag. The intend is to define SOCKFL_CLOEXEC and
> > O_CLOEXEC to the same value. In this case there is zero overhead.
>
>
> Given we will never have 2^32 socket types, and in a sense this is part
> of the type why not just use
>
> socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC, ...)
>
> that would be far far cleaner, no new syscalls on the socket side at all.
That''s not quite true. There is still the problem of accept().
It's worth trying to summarize all of the syscalls that create file
descriptors to get a handle on how many new syscalls might really be
required. AFAIK, the list below is all of the syscalls that create
FDs on Linux.
The following system calls all have a flags argument that either
already has a O_CLOEXEC functionality, or to which that functionality
could be added:
* open()
* openat()
* fcntl(F_DUPFD)
* timerfd_create()
* mq_open() (on Linux MQ descriptors are really just file descriptors)
For the following system calls, we could overload another argument for
the purpose:
* socket() (using the 'type' argument, as per Alan's suggestion)
The following syscalls don't have a flags argument, but does it
matter? For each of them there is an alternative API that can be used
instead, if the functionality is required.
* dup2() -- use fcntl(F_DUPFD) instead
* dup() -- use fcntl(F_DUPFD) instead
* creat() -- use open() instead
The following system call doesn't have a flags argument, but we could
conceivably overload the existing 'fd' argument. When creating a new
file descriptor, the 'fd' argument must be -1. We could say that to
create a new fd, the argument must be say NEW_SIGNALFD, defined as
-MAXINT, ORed with the desired flags.
* signalfd() (glibc API supplies a flags argument, but the syscall
doesn't have one)
The following system calls don't have a flags argument, and the only
way to solve the problem is a new syscall, or sys_indirect().
* eventfd() (glibc API supplies a flags argument, but the syscall
doesn't have one)
* accept()
* pipe()
* inotify_init()
* epoll_create()
So the alternative to sys_indirect(), at least for the purpose of
O_CLOEXEC and similar, would be to create 5 new system calls (or six,
if one finds the signalfd() hack too ugly, which perhaps it is; or 7
if one doesn't like Alan's suggestion for socket() -- if one went the
route of new syscalls, then I'd suggest creating a new socket()-type
syscall with a flags argument).
Cheers,
Michael
--
I'll likely only see replies if they are CCed to mtk.manpages at gmail dot com
next prev parent reply other threads:[~2008-04-24 12:34 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-24 4:03 Ulrich Drepper
2008-04-24 10:25 ` Alan Cox
2008-04-24 12:34 ` Michael Kerrisk [this message]
2008-04-24 14:49 ` Ulrich Drepper
2008-04-24 14:42 ` Alan Cox
2008-04-24 15:19 ` Ulrich Drepper
2008-04-24 15:05 ` Michael Kerrisk
2008-04-24 14:18 ` Ulrich Drepper
2008-04-24 14:24 ` Alan Cox
2008-04-24 15:16 ` Ulrich Drepper
2008-04-24 15:03 ` Alan Cox
2008-04-24 15:44 ` Jakub Jelinek
2008-04-24 15:24 ` Alan Cox
2008-04-24 16:00 ` David Miller
2008-04-24 15:38 ` Alan Cox
2008-04-24 16:09 ` David Miller
2008-04-24 16:45 ` Michael Kerrisk
2008-04-26 22:41 ` dean gaudet
2008-04-24 15:45 ` Ulrich Drepper
2008-04-24 15:27 ` Alan Cox
2008-04-24 16:04 ` Ulrich Drepper
2008-04-24 15:45 ` Alan Cox
2008-04-24 16:06 ` Michael Kerrisk
2008-04-24 16:49 ` Evgeniy Polyakov
2008-04-24 15:29 ` Linus Torvalds
2008-04-24 15:39 ` David Miller
2008-04-24 16:03 ` Michael Kerrisk
2008-04-24 15:42 ` Alan Cox
2008-04-24 16:48 ` Michael Kerrisk
2008-04-24 17:20 ` H. Peter Anvin
2008-04-24 17:31 ` Ulrich Drepper
2008-04-24 17:34 ` H. Peter Anvin
2008-04-24 16:30 ` Linus Torvalds
2008-04-24 16:52 ` Ulrich Drepper
2008-04-24 12:27 ` Michael Kerrisk
2008-04-24 12:46 ` David Collier-Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=517f3f820804240534r3bbbdc52s52a6dfe3f2d14b7f@mail.gmail.com \
--to=mtk.manpages@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=michael.kerrisk@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®