On Tue, Apr 19, 2016 at 4:15 AM, Ingo Molnar <[email protected]> wrote: > > * tip-bot for Dmitry Safonov <[email protected]> wrote: > >> Commit-ID: abfb9498ee1327f534df92a7ecaea81a85913bae >> Gitweb: >> http://git.kernel.org/tip/abfb9498ee1327f534df92a7ecaea81a85913bae >> Author: Dmitry Safonov <[email protected]> >> AuthorDate: Mon, 18 Apr 2016 16:43:43 +0300 >> Committer: Ingo Molnar <[email protected]> >> CommitDate: Tue, 19 Apr 2016 10:44:52 +0200 >> >> x86/entry: Rename is_{ia32,x32}_task() to in_{ia32,x32}_syscall() > > Btw., I'm not _entirely_ happy about the 'IA32' name, but went with this name > for > lack of a better alternative. > > So we have 4 system call modes: > > - 64-bit native > - 32-bit addresses with 64-bit arguments (x32) > - 32-bit compat syscall (x86-32 compatibility on x86-64) > - 32-bit native > > and we have 2 bits of data that are per system call properties: > > - TS_COMPAT in thread_info->status is set/cleared dynamically by the compat > syscall entry code > > - a high bit in pt_regs->orig_ax tells us whether it's an x32 system call. > > So I'd suggest the following renames to harmonize these concepts: > > - CONFIG_IA32_EMULATION => CONFIG_X86_32_ABI > this lines up nicely with: CONFIG_X86_X32_ABI
I think I'd prefer a different interpretation: CONFIG_X86_32_ABI is set if CONFIG_IA32_EMULATION is set *or* CONFIG_X86_32 is set. There is a lot of code that manually looks for that, because what it actually cares about is "do we support 32-bit syscalls". Also, with the syscall cleanups I've been doing, a lot of the code is shared between native 32-bit and 32-on-64 compat, so the distinction between those two modes is slowly shrinking. in_ia32_syscall() is consistent with that idea: it returns true on native 32-bit kernels. --Andy
