All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
To: Ulrich Drepper <drepper-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
	linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] reintroduce accept4
Date: Mon, 27 Oct 2008 20:41:35 -0700	[thread overview]
Message-ID: <20081027204135.a139704e.akpm@linux-foundation.org> (raw)
In-Reply-To: <200810261641.m9QGfotr024285-sQhldQRnEDHy+ZiRM8QlFPXAX3CI6PSWQQ4Iyu8u01E@public.gmane.org>

(cc linux-api)

(cc linux-arch)

On Sun, 26 Oct 2008 12:41:50 -0400 Ulrich Drepper <drepper-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

> This patch reintroduces accept4, replacing paccept.  It's easy to see that
> the patch only removes code and then redirects existing code away from the
> removed functions.  Since the paccept code sans signal handling was never
> in question I think there is no reason to quarantine the patch first.

I'll confess to not having a clue what's going on here.

What is accept4() and why do I want one?  Sigh.  Hopefully others have
been following more closely and have some context.

> I've updated the test program which now looks as follows:

> 
> #include <fcntl.h>
> #include <pthread.h>
> #include <stdio.h>
> #include <unistd.h>
> #include <netinet/in.h>
> #include <sys/socket.h>
> #include <sys/syscall.h>
> 
> #ifdef __x86_64__
> #define __NR_accept4 288
> #define SOCK_CLOEXEC O_CLOEXEC
> #elif __i386__
> #define SYS_ACCEPT4     18
> #define USE_SOCKETCALL 1
> #define SOCK_CLOEXEC O_CLOEXEC
> #else

Well.  This doesn't actually agree with the kernel patch.

>
> ...
>
>  arch/x86/include/asm/unistd_64.h |    4 -
>  include/linux/net.h              |    6 --
>  include/linux/syscalls.h         |    3 -
>  kernel/sys_ni.c                  |    2 
>  net/compat.c                     |   50 ++----------------------
>  net/socket.c                     |   80 ++++-----------------------------------

I'd suggest that i386 is sufficiently common to warrant its inclusion
in the initial patch.

--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Ulrich Drepper <drepper@redhat.com>
Cc: linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
	linux-api@vger.kernel.org
Subject: Re: [PATCH] reintroduce accept4
Date: Mon, 27 Oct 2008 20:41:35 -0700	[thread overview]
Message-ID: <20081027204135.a139704e.akpm@linux-foundation.org> (raw)
In-Reply-To: <200810261641.m9QGfotr024285@hs20-bc2-1.build.redhat.com>

(cc linux-api)

(cc linux-arch)

On Sun, 26 Oct 2008 12:41:50 -0400 Ulrich Drepper <drepper@redhat.com> wrote:

> This patch reintroduces accept4, replacing paccept.  It's easy to see that
> the patch only removes code and then redirects existing code away from the
> removed functions.  Since the paccept code sans signal handling was never
> in question I think there is no reason to quarantine the patch first.

I'll confess to not having a clue what's going on here.

What is accept4() and why do I want one?  Sigh.  Hopefully others have
been following more closely and have some context.

> I've updated the test program which now looks as follows:

> 
> #include <fcntl.h>
> #include <pthread.h>
> #include <stdio.h>
> #include <unistd.h>
> #include <netinet/in.h>
> #include <sys/socket.h>
> #include <sys/syscall.h>
> 
> #ifdef __x86_64__
> #define __NR_accept4 288
> #define SOCK_CLOEXEC O_CLOEXEC
> #elif __i386__
> #define SYS_ACCEPT4     18
> #define USE_SOCKETCALL 1
> #define SOCK_CLOEXEC O_CLOEXEC
> #else

Well.  This doesn't actually agree with the kernel patch.

>
> ...
>
>  arch/x86/include/asm/unistd_64.h |    4 -
>  include/linux/net.h              |    6 --
>  include/linux/syscalls.h         |    3 -
>  kernel/sys_ni.c                  |    2 
>  net/compat.c                     |   50 ++----------------------
>  net/socket.c                     |   80 ++++-----------------------------------

I'd suggest that i386 is sufficiently common to warrant its inclusion
in the initial patch.


  parent reply	other threads:[~2008-10-28  3:41 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-26 16:41 [PATCH] reintroduce accept4 Ulrich Drepper
     [not found] ` <200810261641.m9QGfotr024285-sQhldQRnEDHy+ZiRM8QlFPXAX3CI6PSWQQ4Iyu8u01E@public.gmane.org>
2008-10-28  3:41   ` Andrew Morton [this message]
2008-10-28  3:41     ` Andrew Morton
     [not found]     ` <20081027204135.a139704e.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2008-10-28  4:22       ` Ulrich Drepper
2008-10-28  4:22         ` Ulrich Drepper
     [not found]         ` <490693A3.9070805-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-10-28  4:52           ` Andrew Morton
2008-10-28  4:52             ` Andrew Morton
2008-10-28 12:34   ` Michael Kerrisk
2008-10-28 12:34     ` Michael Kerrisk
2008-11-13 21:51   ` Michael Kerrisk
2008-11-13 21:51     ` Michael Kerrisk
     [not found]     ` <517f3f820811131351l1305b2d2u43ab4e0601d97f93-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-13 22:02       ` Michael Kerrisk
2008-11-13 22:02         ` Michael Kerrisk
     [not found]         ` <cfd18e0f0811131402j7ec6a60cq462916cc9715b9aa-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-13 22:11           ` Michael Kerrisk
2008-11-13 22:11             ` Michael Kerrisk
     [not found]             ` <cfd18e0f0811131411o5b47175dl36b022bc762181e5-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-11-13 22:14               ` Michael Kerrisk
2008-11-13 22:14                 ` Michael Kerrisk
2008-11-13 22:05     ` Andrew Morton
2008-11-13 22:05       ` Andrew Morton
2008-11-13 22:05       ` Andrew Morton
2008-11-13 22:25       ` Paul Mackerras
     [not found]         ` <18716.43376.534965.688695-UYQwCShxghk5kJ7NmlRacFaTQe2KTcn/@public.gmane.org>
2008-11-13 22:28           ` Paul Mackerras
2008-11-13 22:28             ` Paul Mackerras
     [not found]             ` <18716.43543.256621.825529-UYQwCShxghk5kJ7NmlRacFaTQe2KTcn/@public.gmane.org>
2008-11-13 22:57               ` Andrew Morton
2008-11-13 22:57             ` Andrew Morton
2008-11-13 22:57             ` Andrew Morton
2008-11-13 22:57             ` Andrew Morton
2008-11-13 22:57               ` Andrew Morton
     [not found]               ` <20081113145737.96898aaf.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2008-11-14  0:07                 ` David Miller
2008-11-14  0:07                   ` David Miller
2008-11-14 15:24               ` Michael Kerrisk
2008-11-14 17:40               ` Michael Kerrisk
2008-11-13 22:28           ` Paul Mackerras
2008-11-13 22:28         ` Paul Mackerras
     [not found]       ` <20081113140541.23754cad.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2008-11-14 15:24         ` Michael Kerrisk
2008-11-14 15:24           ` 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=20081027204135.a139704e.akpm@linux-foundation.org \
    --to=akpm-de/tnxtf+jlsfhdxvbkv3wd2fqjk+8+b@public.gmane.org \
    --cc=drepper-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.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.