On Wednesday 18 November 2015 09:25:40 Andreas Schwab wrote:
> Arnd Bergmann <a...@arndb.de> writes:
>
> > On Wednesday 18 November 2015 00:16:55 Yury Norov wrote:
> >>
> >> +/* IPC_64 */
> >> +asmlinkage long ilp32_sys_msgctl(int first, int second, void __user *uptr)
> >> +{
> >> + return compat_sys_msgctl(first, second | IPC_64, uptr);
> >> +}
> >> +#define compat_sys_msgctl ilp32_sys_msgctl
> >> +
> >> +asmlinkage long ilp32_sys_shmctl(int first, int second, void __user *uptr)
> >> +{
> >> + return compat_sys_shmctl(first, second | IPC_64, uptr);
> >> +}
> >> +#define compat_sys_shmctl ilp32_sys_shmctl
> >> +
> >> +asmlinkage long ilp32_sys_semctl(int first, int second, int third, int
> >> arg)
> >> +{
> >> + return compat_sys_semctl(first, second, third | IPC_64, arg);
> >> +}
> >> +#define compat_sys_semctl ilp32_sys_semctl
> >>
> >
> > I wonder if this would be any simpler by changing compat_ipc_parse_version()
>
> This cries for a generic solution. Other archs migrating to separate
> ipc syscalls will want to avoid the whole IPC_64 business for them, even
> if they need to retain [compat_]ipc_parse_version for sys_ipc
> compatibility.
Agreed. I think all architectures are moving that way now, so we should
really try to get all cases right now.
I've done a complete list of what the architectures (see
https://docs.google.com/spreadsheets/d/18GxXEHE2ywnSr-SPoGFd1ABz6wEM1ex-JMu5lEraaH8/
)
We have these categories:
1. uses IPC_PARSE_VERSION with sys_ipc, and has just introduced
separate syscalls:
arm, avr32, powerpc, x86-32
2. uses IPC_PARSE_VERSION with sys_ipc, and has not yet introduced
separate syscalls (currently producing a compile warning):
cris, frv, m32r, m68k, mips (o32), mn10300, s390, sh32, sparc
3. uses IPC_PARSE_VERSION with separate syscalls:
alpha, blackfin, microblaze, mips (n32/64), xtensa
4a. only new-style IPC with separate syscalls:
ia64, parisc, sh64
4b. only new-style IPC with separate syscalls, using generic syscall
table:
arc, arm64, c6x, h8300, hexagon, metag, nios2, openrisc, score,
tile, unicore32
So we should probably fix 1. and 2. before it's too late, but make
sure we don't break 3. in the process.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
