From: "Michael Kerrisk" <mtk.manpages@gmail.com>
To: "Ulrich Drepper" <drepper@redhat.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 11:52:35 +0200 [thread overview]
Message-ID: <517f3f820804280252h753c8cacv7fe9580f96dcf1ce@mail.gmail.com> (raw)
In-Reply-To: <200804262224.m3QMOP3a006296@devserv.devel.redhat.com>
[CC+=Alan Cox]
On 4/27/08, Ulrich Drepper <drepper@redhat.com> wrote:
> This version of the patch hopefully integrates all of the requested
> changes:
>
> - the sock_map_fd interface is changed and all in-tree users changed.
> No additional function anymore
>
> - there is a helper function to convert the new socket flags into
> file flags. Shared by all three functions
>
> - the new accept interface is now paccept() which adds the flag
> parameter as well as a signal mask.
>
> - not changed from the last version: the paccet() function takes
> a flags parameter with the same value as the ORed flags for
> socket() and socketpair(). Seems cleaner.
Ulrich,
This is ugly. Why invent a diffent set of flags here. I agree with
your earlier statement that new syscalls would be cleaner. If, as
seems to be the case, we are going to create new syscalls for
eventfd()
signalfd()
accept()
dup2()
epoll_create()
pipe()
inotify_init()
(I've not seen those last two yet, but I assume you are going to do them.)
then *please* let's go the hwole way cleanly, and have new syscalls
also for socketpair() and socket(), and make all of the new syscalls
use the same flags. Creating a different set of flags just to avoid a
couple of extra sycalls is ugly. (You yourself asserted similar in
saying that dup3() is better than adding an extra flag to fcntl(), and
I don't disagree.)
Cheers,
Michael
next prev parent reply other threads:[~2008-04-28 9:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-26 22:24 Ulrich Drepper
2008-04-28 9:52 ` Michael Kerrisk [this message]
2008-04-28 14:13 ` Ulrich Drepper
2008-04-28 14:51 ` Michael Kerrisk
2008-04-28 15:13 ` Ulrich Drepper
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=517f3f820804280252h753c8cacv7fe9580f96dcf1ce@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=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®