Re: [RFC] Rename various 'IA32' uses in arch/x86/ code

[H. Peter Anvin]

We have generally used i386 as opposed to x86 for that purpose.  IA32 in MSR names is part of the MSR name and should not be taken out.

On June 18, 2015 10:49:33 AM PDT, Brian Gerst <brgerst@xxxxxxxxx> wrote:
>On Thu, Jun 18, 2015 at 12:49 PM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>>
>> * H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>>
>>> On 06/08/2015 03:24 PM, tip-bot for Ingo Molnar wrote:
>>> > Commit-ID:  bace7117d3fb59a6ed7ea1aa6c8994df6a28a72a
>>> > Gitweb:    
>http://git.kernel.org/tip/bace7117d3fb59a6ed7ea1aa6c8994df6a28a72a
>>> > Author:     Ingo Molnar <mingo@xxxxxxxxxx>
>>> > AuthorDate: Mon, 8 Jun 2015 21:20:26 +0200
>>> > Committer:  Ingo Molnar <mingo@xxxxxxxxxx>
>>> > CommitDate: Mon, 8 Jun 2015 23:43:38 +0200
>>> >
>>> > x86/asm/entry: (Re-)rename __NR_entry_INT80_compat_max to
>__NR_syscall_compat_max
>>> >
>>> > Brian Gerst noticed that I did a weird rename in the following
>commit:
>>> >
>>> >    b2502b418e63 ("x86/asm/entry: Untangle 'system_call' into two
>entry points: entry_SYSCALL_64 and entry_INT80_32")
>>> >
>>> > which renamed __NR_ia32_syscall_max to
>__NR_entry_INT80_compat_max.
>>> >
>>> > Now the original name was a misnomer, but the new one is a
>misnomer as well,
>>> > as all the 32-bit compat syscall entry points (sysenter, syscall)
>share the
>>> > system call table, not just the INT80 based one.
>>> >
>>> > Rename it to __NR_syscall_compat_max.
>>> >
>>>
>>> The original one wasn't really a misnomer, as it referred to the
>ia32
>>> system calls specifically, but this works too.
>>
>> It was a misnomer, because what are the 'ia32 system calls'? We have
>no Intel
>> specific system calls!
>>
>> The term 'IA32' (Intel Architecture 32-bit) is a misnomer in many
>existing
>> arch/x86/ symbol, function and file names, and most of them should be
>renamed.
>>
>> Some common examples, with a suggested rename target:
>>
>>  stack_frame_ia32               -> stack_frame_compat
>>  IA32_RT_SIGFRAME_sigcontext    -> COMPAT_RT_SIGFRAME_sigcontext
>>  sigcontext_ia32                -> sigcontext_compat
>>  user_i387_ia32_struct          -> user_i387_compat_struct
>>  TIF_IA32                       -> TIF_COMPAT
>>
>> and here a few 'ia32' misnomers that should be addressed not via
>simple renames,
>> but via transformations to existing compat facilities:
>>
>>  CONFIG_IA32_EMULATION          -> partly eliminate, partly covert to
>CONFIG_COMPAT use
>
>I think we still want a symbol for code that is exclusive to 32-bit
>compatibility (like entry and signal code) to keep it separate from
>X32 which also wants CONFIG_COMPAT.  If I get time this weekend I'll
>get the patchset to do the separation updated to the tip branch.
>
>>  is_ia32_task()                 -> convert to is_compat_task() use
>>
>> This holds for file names as well, for example:
>>
>>  arch/x86/ia32/                 -> arch/x86/compat/
>>  arch/x86/ia32/ia32_aout.c      -> arch/x86/compat/aout.c
>>  arch/x86/ia32/ia32_signal.c    -> arch/x86/compat/signal.c
>>  arch/x86/ia32/sys_ia32.c       -> arch/x86/compat/sys.c
>>
>> There are a number of symbols where the 'IA32' name is probably fine:
>for example
>> the various Intel-specific MSR names - or even cross-CPU MSR names
>that AMD uses
>> but which got first introduced on Intel CPUs.
>>
>> For generic names that deal with 32-bit compat, 'ia32' is a misnomer.
>>
>> If there's consensus for the above (re-)naming schemes I can start
>doing them.
>
>As long as there is no confusion between this and X32, I am fine with
>it.
>
>--
>Brian Gerst

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/