On Fri, 9 Dec 2011 10:29:07 -0500
Chris Metcalf [off-list ref] wrote:

When using the "compat" APIs, architectures will generally want to
be able to make direct syscalls to msgsnd(), shmctl(), etc., and
in the kernel we would want them to be handled directly by
compat_sys_xxx() functions, as is true for other compat syscalls.

However, for historical reasons, several of the existing compat IPC
syscalls do not do this.  semctl() expects a pointer to the fourth
argument, instead of the fourth argument itself.  msgsnd(), msgrcv()
and shmat() expect arguments in different order.

This change adds an __ARCH_WANT_OLD_COMPAT_IPC define that can be
set in <asm/compat.h> to preserve this behavior for ports that use it
(x86, sparc, powerpc, s390, and mips).  No actual semantics are changed
for those architectures, and there is only a minimal amount of code
refactoring in ipc/compat.c.

Newer architectures like tile (and perhaps future architectures such
as arm64 and unicore64) should not supply this define, and thus can
avoid having any IPC-specific code at all in their architecture-specific
compat layer.  In the same vein, if this define is omitted, IPC_64 mode
is assumed, since that's what the <asm-generic> headers expect.

The workaround code in "tile" for msgsnd() and msgrcv() is removed
with this change; it also fixes the bug that shmat() and semctl() were
not being properly handled.

What would we need to do to get all architectures using the new
interfaces, and remove __ARCH_WANT_OLD_COMPAT_IPC?

Regarding the implementation: rather than patching the header
files, it would be more conventional (and arguably better) to add

	select ARCH_WANT_OLD_COMPAT_IPC

to arch/*/Kconfig, then use CONFIG_ARCH_WANT_OLD_COMPAT_IPC.