From: Andrew Morton <akpm@linux-foundation.org>
To: Ulrich Drepper <drepper@redhat.com>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
davidel@xmailserver.org, mtk.manpages@gmail.com,
torvalds@linux-foundation.org, Roland McGrath <roland@redhat.com>
Subject: Re: [PATCH 02/18] flag parameters: paccept
Date: Mon, 12 May 2008 21:10:56 -0700 [thread overview]
Message-ID: <20080512211056.16e07167.akpm@linux-foundation.org> (raw)
In-Reply-To: <200805062118.m46LI7SS004041@devserv.devel.redhat.com>
On Tue, 6 May 2008 17:18:07 -0400 Ulrich Drepper <drepper@redhat.com> wrote:
> This patch is by far the most complex in the series. It adds a new syscall
> paccept. This syscall differs from accept in that it adds (at the userlevel)
> two additional parameters:
>
> - a signal mask
> - a flags value
>
> The flags parameter can be used to set flag like SOCK_CLOEXEC. This is
> imlpemented here as well. Some people argued that this is a property
> which should be inherited from the file desriptor for the server but
> this is against POSIX. Additionally, we really want the signal mask
> parameter as well (similar to pselect, ppoll, etc). So an interface
> change in inevitable.
>
> The flag value is the same as for socket and socketpair. I think
> diverging here will only create confusion. Similar to the filesystem
> interfaces where the use of the O_* constants differs, it is acceptable
> here.
>
> The signal mask is handled as for pselect etc. The mask is temporarily
> installed for the thread and removed before the call returns. I modeled
> the code after pselect. If there is a problem it's likely also in
> pselect.
>
> For architectures which use socketcall I maintained this interface
> instead of adding a system call. The symmetry shouldn't be broken.
>
> The following test must be adjusted for architectures other than x86 and
> x86-64 and in case the syscall numbers changed.
Am getting moderately bored of these patches :(
arm exploded thusly:
net/socket.c: In function `sys_paccept':
net/socket.c:1534: error: implicit declaration of function `set_restore_sigmask'
because afacit arm doesn't implement set_restore_sigmask() and nor does
it need to, because it doesn't set HAVE_SET_RESTORE_SIGMASK.
I will continue to fumble along in the rc2-mm1 direction. Fixes against that
kernel would suit, thanks.
next prev parent reply other threads:[~2008-05-13 4:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-06 21:18 [PATCH 02/18] flag parameters: paccept Ulrich Drepper
2008-05-08 22:38 ` Andrew Morton
2008-05-08 22:50 ` David Miller
2008-05-08 22:50 ` Roland McGrath
2008-05-08 22:58 ` David Miller
2008-05-09 8:01 ` Ulrich Drepper
2008-05-13 4:10 ` Andrew Morton [this message]
2008-05-13 4:42 ` Ulrich Drepper
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=20080512211056.16e07167.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=davidel@xmailserver.org \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=roland@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.