From: Ulrich Drepper <drepper@redhat.com>
To: Michael Kerrisk <mtk.manpages@googlemail.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
akpm@linux-foundation.org, torvalds@linux-foundation.org
Subject: Re: [PATCH] paccept, socket, socketpair w/flags
Date: Mon, 28 Apr 2008 08:13:31 -0700 [thread overview]
Message-ID: <4815E99B.2010903@redhat.com> (raw)
In-Reply-To: <cfd18e0f0804280751x21833b51y4b1f6f7ce3201d0d@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Kerrisk wrote:
> You have said it would be cleaner to have new syscalls for socket()
> and socketpair(). I understand your reasoning for that to be that
> doing so is cleaner than overloading the type argument of the existing
> versions of these syscalls. I agree. So, since you are adding new
> syscalls for all of the other interfaces, why not do it for these two
> syscalls also?
If the range of the existing parameter can indeed be restricted as
needed for the flags it is the better approach for programmers since all
that is needed for a programmer to do is to write
fd = socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC, 0);
if (fd == -1 && errno == EINVAL)
{
fd = socket(PF_INET, SOCK_STREAM, 0);
if (fd != -1)
fcntl(fd, F_SETFD, FD_CLOEXEC);
}
No autoconf code needed to detect the presence of a new function. You
can even imagine that convenience libraries will do the above
automatically (not libc, though, where you want to recognize this
situation).
> Okay -- I see your point (and I didn't read your patches closely
> enough). However, the rationale for the implementations proposed to
> date isn't very clear. So far we have the following new flags:
>
> timerfd_create() -- TFD_CLOEXEC
> signalfd4() -- SFD_CLOEXEC
> eventfd2() -- EFD_CLOEXEC
> epoll_create2() -- EPOLL_CLOEXEC
> open() (and openat()), dup3() -- all use O_CLOEXEC
> socketpair(), socket(), paccept -- all use SOCK_CLOEXEC
> pipe2() -- to be determined
Use O_CLOEXEC, normal filesystem operation.
> inotify_init2() -- to be determined
New flag.
> It would help if you laid out your reasoning for creating distinct
> flags for some syscalls but not others. For example, is the
> assumption here that socketpair(), socket(), and paccept() will always
> use the same set of flags?
Yes, they are all related interfaces. Using the same name indicates
similarity.
And just to complicate things even more:
if we'd go with sys_indirect we can have single way to specify
close-on-exec for all syscalls. That would be at the syscall level. At
the API level we'd still need separate names and possibly values.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFIFemb2ijCOnn/RHQRAjNCAJ0QCvEJoynwbPveUZQqsyVnEAHtmgCZAe0R
jNlcvQFI06n2ckFhEqUcEbE=
=sJhN
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2008-04-28 15:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-26 22:24 [PATCH] paccept, socket, socketpair w/flags Ulrich Drepper
2008-04-28 9:52 ` Michael Kerrisk
2008-04-28 14:13 ` Ulrich Drepper
2008-04-28 14:51 ` Michael Kerrisk
2008-04-28 15:13 ` Ulrich Drepper [this message]
2008-04-28 15:29 ` Michael Kerrisk
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=4815E99B.2010903@redhat.com \
--to=drepper@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=mtk.manpages@googlemail.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;
as well as URLs for NNTP newsgroup(s).