[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <517f3f820804280252h753c8cacv7fe9580f96dcf1ce@mail.gmail.com>
Date: Mon, 28 Apr 2008 11:52:35 +0200
From: "Michael Kerrisk" <mtk.manpages@...il.com>
To: "Ulrich Drepper" <drepper@...hat.com>
Cc: "Michael Kerrisk" <mtk.manpages@...il.com>,
"Alan Cox" <alan@...rguk.ukuu.org.uk>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
akpm@...ux-foundation.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH] paccept, socket, socketpair w/flags
[CC+=Alan Cox]
On 4/27/08, Ulrich Drepper <drepper@...hat.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
--
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/
Powered by blists - more mailing lists