sys_recvmmsg: wire up or not?

sys_recvmmsg: wire up or not?

[Geert Uytterhoeven]

On m68k, I get:

<stdin>:1523:2: warning: #warning syscall recvmmsg not implemented

so I started to wire up sys_recvmmsg.
Then I noticed it's already accessible, through sys_socketcall, as m68k defines
__ARCH_WANT_SYS_SOCKETCALL. So I guess this is a false positive?

Surprisingly, several architectures have both defined __ARCH_WANT_SYS_SOCKETCALL
and wired up sys_recvmmsg. Is this intentional?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: sys_recvmmsg: wire up or not?

[Arnd Bergmann]

On Saturday 26 December 2009, Geert Uytterhoeven wrote:
> <stdin>:1523:2: warning: #warning syscall recvmmsg not implemented
> 
> so I started to wire up sys_recvmmsg.
> Then I noticed it's already accessible, through sys_socketcall, as m68k defines
> __ARCH_WANT_SYS_SOCKETCALL. So I guess this is a false positive?

Yes.

> Surprisingly, several architectures have both defined __ARCH_WANT_SYS_SOCKETCALL
> and wired up sys_recvmmsg. Is this intentional?

It's also rather inconsistent with the last socket call that was added, sys_accept4.
Some architectures that normally define socket calls (parisc, sh) are missing both
accept4 and recvmmsg, while others that don't have recvmsg now get recvmmsg.

In particular, i386 has recvmmsg now, which caused the warning that you saw.
I guess that one should be removed, and maybe we need a better logic for
determining which syscalls you actually want. Deriving it from asm-generic/unistd.h
instead of arch/x86/include/asm/unistd_32.h is probably better, but would still
give the wrong answer for multiplexed system calls like socketcall or ipc on 
existing architectures.

	Arnd

Re: sys_recvmmsg: wire up or not?

[Benjamin Herrenschmidt]

> It's also rather inconsistent with the last socket call that was added, sys_accept4.
> Some architectures that normally define socket calls (parisc, sh) are missing both
> accept4 and recvmmsg, while others that don't have recvmsg now get recvmmsg.
> 
> In particular, i386 has recvmmsg now, which caused the warning that you saw.
> I guess that one should be removed, and maybe we need a better logic for
> determining which syscalls you actually want. Deriving it from asm-generic/unistd.h
> instead of arch/x86/include/asm/unistd_32.h is probably better, but would still
> give the wrong answer for multiplexed system calls like socketcall or ipc on 
> existing architectures.

Anything happening here ? We're getting that warning on ppc too despite
the fact that we use socketcall like x86... Should checksyscall be made
smarter or the syscall just removed from x86 ? :-)

Cheers,
Ben.

Re: sys_recvmmsg: wire up or not?

[Benjamin Herrenschmidt]

> It's also rather inconsistent with the last socket call that was added, sys_accept4.
> Some architectures that normally define socket calls (parisc, sh) are missing both
> accept4 and recvmmsg, while others that don't have recvmsg now get recvmmsg.
> 
> In particular, i386 has recvmmsg now, which caused the warning that you saw.
> I guess that one should be removed, and maybe we need a better logic for
> determining which syscalls you actually want. Deriving it from asm-generic/unistd.h
> instead of arch/x86/include/asm/unistd_32.h is probably better, but would still
> give the wrong answer for multiplexed system calls like socketcall or ipc on 
> existing architectures.

Anything happening here ? We're getting that warning on ppc too despite
the fact that we use socketcall like x86... Should checksyscall be made
smarter or the syscall just removed from x86 ? :-)

Cheers,
Ben.

Re: sys_recvmmsg: wire up or not?

[David Miller]

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Thu, 14 Jan 2010 15:20:33 +1100

> Anything happening here ? We're getting that warning on ppc too despite
> the fact that we use socketcall like x86... Should checksyscall be made
> smarter or the syscall just removed from x86 ? :-)

I think it's better to trap directly to the system call rather
than going through yet another demultiplexer.

I severely regretted using sys_socketcall initially on sparc32
because it added a few microseconds to socket syscall latency
(cpus back then were slow :-)

Re: sys_recvmmsg: wire up or not?

[Benjamin Herrenschmidt]

On Wed, 2010-01-13 at 20:28 -0800, David Miller wrote:
> > Anything happening here ? We're getting that warning on ppc too
> despite
> > the fact that we use socketcall like x86... Should checksyscall be
> made
> > smarter or the syscall just removed from x86 ? :-)
> 
> I think it's better to trap directly to the system call rather
> than going through yet another demultiplexer.
> 
> I severely regretted using sys_socketcall initially on sparc32
> because it added a few microseconds to socket syscall latency
> (cpus back then were slow :-) 

Oh I definitely agree that a direct syscall is better, and I wonder in
fact if I should add new syscalls in addition to socketcall for powerpc,
for glibc to do a slow migration :-) I was just wondering about the
inconsistency for archs like us who have socketcall today, to also have
to define the syscall ...

IE. I'd rather have them all duplicated into real syscalls than some of
them only in socketcall and some on both since that will make any kind
of userspace transition even more hellish.

Cheers,
Ben.

Re: sys_recvmmsg: wire up or not?

[Russell King]

On Thu, Jan 14, 2010 at 05:59:39PM +1100, Benjamin Herrenschmidt wrote:
> Oh I definitely agree that a direct syscall is better, and I wonder in
> fact if I should add new syscalls in addition to socketcall for powerpc,
> for glibc to do a slow migration :-) I was just wondering about the
> inconsistency for archs like us who have socketcall today, to also have
> to define the syscall ...

On ARM, we used to use socketcall exclusively.  We've since added all
the direct socket and IPC calls to our syscall table as part of the
big EABI shakeup.  They certainly get used on EABI, whereas OABI has
a choice.

They were made available in two stages - first the numbers were reserved
and the calls were added to the call table.  A few years later, we
exposed the syscall numbers in unistd.h.

It's now been almost 4 years since this was done, and there have been
no bug reports.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: sys_recvmmsg: wire up or not?

[Benjamin Herrenschmidt]

On Thu, 2010-01-14 at 09:33 +0000, Russell King wrote:
> On ARM, we used to use socketcall exclusively.  We've since added all
> the direct socket and IPC calls to our syscall table as part of the
> big EABI shakeup.  They certainly get used on EABI, whereas OABI has
> a choice.
> 
> They were made available in two stages - first the numbers were
> reserved
> and the calls were added to the call table.  A few years later, we
> exposed the syscall numbers in unistd.h.
> 
> It's now been almost 4 years since this was done, and there have been
> no bug reports. 

Agreed. It's definitely a switch we should do on powerpc. I'll look into
it after LCA.

Cheers,
Ben.

Re: sys_recvmmsg: wire up or not?

[Paul Mundt]

On Thu, Jan 14, 2010 at 05:59:39PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2010-01-13 at 20:28 -0800, David Miller wrote:
> > > Anything happening here ? We're getting that warning on ppc too
> > despite
> > > the fact that we use socketcall like x86... Should checksyscall be
> > made
> > > smarter or the syscall just removed from x86 ? :-)
> > 
> > I think it's better to trap directly to the system call rather
> > than going through yet another demultiplexer.
> > 
> > I severely regretted using sys_socketcall initially on sparc32
> > because it added a few microseconds to socket syscall latency
> > (cpus back then were slow :-) 
> 
> Oh I definitely agree that a direct syscall is better, and I wonder in
> fact if I should add new syscalls in addition to socketcall for powerpc,
> for glibc to do a slow migration :-) I was just wondering about the
> inconsistency for archs like us who have socketcall today, to also have
> to define the syscall ...
> 
> IE. I'd rather have them all duplicated into real syscalls than some of
> them only in socketcall and some on both since that will make any kind
> of userspace transition even more hellish.
> 
Presumably you're going to have to support both given that binaries with
both ABIs are going to be left around for the forseeable future. We
started out with socketcall on sh64 with the initial ABI and then
transitioned over to broken out direct system calls. While having both is
a bit inconsistent, it's not really something that can be avoided until
all of the old binaries go away. There are certainly enough architectures
today that provide both that you shouldn't really run in to any nasty
surprises at least.

32-bit SH only uses socketcall at the moment, but I'm also inclined to
add in the broken out versions and start migrating glibc over.

Unfortunately there are not a lot of good options for the syscall checker
with things like this however, given that some platforms will want one or
the other or both ;-)

Re: sys_recvmmsg: wire up or not?

[Paul Mundt]

On Thu, Jan 14, 2010 at 05:59:39PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2010-01-13 at 20:28 -0800, David Miller wrote:
> > > Anything happening here ? We're getting that warning on ppc too
> > despite
> > > the fact that we use socketcall like x86... Should checksyscall be
> > made
> > > smarter or the syscall just removed from x86 ? :-)
> > 
> > I think it's better to trap directly to the system call rather
> > than going through yet another demultiplexer.
> > 
> > I severely regretted using sys_socketcall initially on sparc32
> > because it added a few microseconds to socket syscall latency
> > (cpus back then were slow :-) 
> 
> Oh I definitely agree that a direct syscall is better, and I wonder in
> fact if I should add new syscalls in addition to socketcall for powerpc,
> for glibc to do a slow migration :-) I was just wondering about the
> inconsistency for archs like us who have socketcall today, to also have
> to define the syscall ...
> 
> IE. I'd rather have them all duplicated into real syscalls than some of
> them only in socketcall and some on both since that will make any kind
> of userspace transition even more hellish.
> 
Presumably you're going to have to support both given that binaries with
both ABIs are going to be left around for the forseeable future. We
started out with socketcall on sh64 with the initial ABI and then
transitioned over to broken out direct system calls. While having both is
a bit inconsistent, it's not really something that can be avoided until
all of the old binaries go away. There are certainly enough architectures
today that provide both that you shouldn't really run in to any nasty
surprises at least.

32-bit SH only uses socketcall at the moment, but I'm also inclined to
add in the broken out versions and start migrating glibc over.

Unfortunately there are not a lot of good options for the syscall checker
with things like this however, given that some platforms will want one or
the other or both ;-)

Re: sys_recvmmsg: wire up or not?

[Benjamin Herrenschmidt]

On Tue, 2010-01-19 at 16:21 +0900, Paul Mundt wrote:
> 
> > IE. I'd rather have them all duplicated into real syscalls than some of
> > them only in socketcall and some on both since that will make any kind
> > of userspace transition even more hellish.
> > 
> Presumably you're going to have to support both given that binaries with
> both ABIs are going to be left around for the forseeable future. We
> started out with socketcall on sh64 with the initial ABI and then
> transitioned over to broken out direct system calls. While having both is
> a bit inconsistent, it's not really something that can be avoided until
> all of the old binaries go away. There are certainly enough architectures
> today that provide both that you shouldn't really run in to any nasty
> surprises at least.

I agree, my point was more like I'd rather not add the syscall for
recvmmsg only right now, and others later, and instead of an
all-or-nothing approach, ie, add all the syscalls at once (while keeping
the socketcall around of course). That would make glibc work easier not
having to track syscall availability on a per-syscall basis etc...

Cheers,
Ben.

> 32-bit SH only uses socketcall at the moment, but I'm also inclined to
> add in the broken out versions and start migrating glibc over.
> 
> Unfortunately there are not a lot of good options for the syscall checker
> with things like this however, given that some platforms will want one or
> the other or both ;-)
> 
>