x86, compat: convert ia32 layer to use
in [Kernel]
|
Prev: [PATCH 04/40] trace, powerpc: Implement raw syscall tracepoints on PowerPC
Next: [PATCH 06/40] x86: add arch_compat_syscall_addr()
From: Christoph Hellwig on 23 Jun 2010 06:20 Any reason we need to differenciate between COMPAT_SYSCALL_DEFINE and ARCH_COMPAT_SYSCALL_DEFINE? We don't need this for native system calls, so I can't see the reason to do it for compat system calls. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Frederic Weisbecker on 23 Jun 2010 06:40 On Wed, Jun 23, 2010 at 12:14:02PM +0200, Christoph Hellwig wrote: > Any reason we need to differenciate between COMPAT_SYSCALL_DEFINE and > ARCH_COMPAT_SYSCALL_DEFINE? We don't need this for native system calls, > so I can't see the reason to do it for compat system calls. > I think we wanted that to keep the sys32_ prefixed based naming, to avoid collisions with generic compat handler names. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Hellwig on 23 Jun 2010 06:50 On Wed, Jun 23, 2010 at 12:36:21PM +0200, Frederic Weisbecker wrote: > I think we wanted that to keep the sys32_ prefixed based naming, to avoid > collisions with generic compat handler names. For native syscalls we do this by adding a arch prefix inside the syscall name, e.g.: arch/s390/kernel/sys_s390.c:SYSCALL_DEFINE(s390_fallocate)(int fd, int mode, loff_t offset, arch/sparc/kernel/sys_sparc_64.c:SYSCALL_DEFINE1(sparc_pipe_real, struct pt_regs *, regs) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Frederic Weisbecker on 23 Jun 2010 07:50 On Wed, Jun 23, 2010 at 12:46:04PM +0200, Christoph Hellwig wrote: > On Wed, Jun 23, 2010 at 12:36:21PM +0200, Frederic Weisbecker wrote: > > I think we wanted that to keep the sys32_ prefixed based naming, to avoid > > collisions with generic compat handler names. > > For native syscalls we do this by adding a arch prefix inside the > syscall name, e.g.: > > arch/s390/kernel/sys_s390.c:SYSCALL_DEFINE(s390_fallocate)(int fd, int mode, loff_t offset, > arch/sparc/kernel/sys_sparc_64.c:SYSCALL_DEFINE1(sparc_pipe_real, struct pt_regs *, regs) In fact we sort of wanted to standardize the name of arch overriden compat syscalls, so that userspace programs playing with syscalls tracing won't have to deal with arch naming differences. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 23 Jun 2010 15:30
On 06/23/2010 04:41 AM, Frederic Weisbecker wrote: > On Wed, Jun 23, 2010 at 12:46:04PM +0200, Christoph Hellwig wrote: >> On Wed, Jun 23, 2010 at 12:36:21PM +0200, Frederic Weisbecker wrote: >>> I think we wanted that to keep the sys32_ prefixed based naming, to avoid >>> collisions with generic compat handler names. >> >> For native syscalls we do this by adding a arch prefix inside the >> syscall name, e.g.: >> >> arch/s390/kernel/sys_s390.c:SYSCALL_DEFINE(s390_fallocate)(int fd, int mode, loff_t offset, >> arch/sparc/kernel/sys_sparc_64.c:SYSCALL_DEFINE1(sparc_pipe_real, struct pt_regs *, regs) > > In fact we sort of wanted to standardize the name of arch overriden compat > syscalls, so that userspace programs playing with syscalls tracing won't have > to deal with arch naming differences. > That seems totally wrong in so many ways. What userspace sees is the system call name, e.g. fallocate or pipe. It should *not* be visible to userspace that there is an arch-specici implementation. There are already a huge amount of gratuitous user space ABI differences, of course, partly because we *still* don't actually have a systematic model for argument passing. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |