Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756175AbbFRRtn (ORCPT ); Thu, 18 Jun 2015 13:49:43 -0400 Received: from mail-oi0-f49.google.com ([209.85.218.49]:34450 "EHLO mail-oi0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752639AbbFRRtd (ORCPT ); Thu, 18 Jun 2015 13:49:33 -0400 MIME-Version: 1.0 In-Reply-To: <20150618164912.GA8557@gmail.com> References: <55808579.4050004@zytor.com> <20150618164912.GA8557@gmail.com> Date: Thu, 18 Jun 2015 13:49:33 -0400 Message-ID: Subject: Re: [RFC] Rename various 'IA32' uses in arch/x86/ code From: Brian Gerst To: Ingo Molnar Cc: "H. Peter Anvin" , Linux Kernel Mailing List , Peter Zijlstra , Borislav Petkov , Thomas Gleixner , Andrew Morton , Linus Torvalds , Denys Vlasenko , Andy Lutomirski , linux-tip-commits@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3477 Lines: 80 On Thu, Jun 18, 2015 at 12:49 PM, Ingo Molnar wrote: > > * H. Peter Anvin 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 >> > AuthorDate: Mon, 8 Jun 2015 21:20:26 +0200 >> > Committer: Ingo Molnar >> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/