Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753205AbbFHTOl (ORCPT ); Mon, 8 Jun 2015 15:14:41 -0400 Received: from mail-wg0-f48.google.com ([74.125.82.48]:34969 "EHLO mail-wg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751459AbbFHTOd (ORCPT ); Mon, 8 Jun 2015 15:14:33 -0400 Date: Mon, 8 Jun 2015 21:14:28 +0200 From: Ingo Molnar To: Brian Gerst Cc: Linus Torvalds , Denys Vlasenko , Frederic Weisbecker , Kees Cook , Borislav Petkov , Linux Kernel Mailing List , Alexei Starovoitov , Oleg Nesterov , Will Drewry , Andy Lutomirski , Steven Rostedt , the arch/x86 maintainers , "H. Peter Anvin" Subject: Re: [PATCH] x86/asm/entry/32: Rename labels in INT 0x80 code path Message-ID: <20150608191428.GA7549@gmail.com> References: <1433702514-31086-1-git-send-email-dvlasenk@redhat.com> <20150608053537.GA18307@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4150 Lines: 102 * Brian Gerst wrote: > On Mon, Jun 8, 2015 at 1:35 AM, Ingo Molnar wrote: > > > > * Linus Torvalds wrote: > > > >> On Jun 7, 2015 11:42 AM, "Denys Vlasenko" wrote: > >> > > >> > Rename it to ia32_int80_target. > >> > >> Btw, could we arrive to get rid of the idiotic "ia32" naming too? It's wrong, > >> and it harkens back to the days when intel thought itanium makes sense and > >> wanted to talk about "intel architecture". > > > > Absolutely, I've been slowly eliminating uses of it - that naming is very > > annoying. > > > > Another thing I'm doing is to slowly remove references to 'emulation' - we > > don't emulate 32-bit in any way, we implement various 32-bit syscall ABIs (old > > a new) natively. > > > > I'd like to remove CONFIG_IA32_EMULATION from the .config as well - it offers > > nothing real over CONFIG_COMPAT. > > A few months ago I started working on a set of patches to decouple the X32 > support from the 32-bit compat support. There is actually quite a bit of > non-shared code between the two, mainly signal handling and syscall entries. > The code used by both should be CONFIG_COMPAT, but separate config defines > should be kept for the non-shared code. That would allow X32 support without > dragging in all of the 32-bit compat support. I never finished it because I > couldn't find a current distribution that supported X32 out of the box to test > with. So yes, x32 support outlined some of the shortcomings of our current compat code, which pretty much assumes that there's just a single compat model - which is far away from reality on x86, which has 3 compat modes: - 16-bit registers, 16-bit memory model (vm86 mode) - 32-bit registers, 32-bit memory model (CONFIG_COMPAT) - 64-bit registers, 32-bit memory model (CONFIG_X86_X32_ABI) and both the naming and (necessarily) the organization of the code is suffering a bit from that currently. Perhaps we could improve things by reorganizing it along 'multiple ABIs' idiom, which x32 partially already started. The most important aspect of 'compat', in terms of complexity, is pointer size, i.e. the memory model. Register width of the ABI matters too, but is mostly resolved early on during system call entry. Pointer size details matter all across the kernel, in system calls that interact via user-space pointers. > I agree on dropping the word emulation though, since the hardware provides a > full 32-bit environment. I suggest CONFIG_X86_32_COMPAT (or > CONFIG_COMPAT_X86_32) as a new name. So why not just use CONFIG_COMPAT and allow the configuration of the 3 system call ABIs: - CONFIG_SYSCALL_ABI_X32 - CONFIG_SYSCALL_ABI_32 - CONFIG_SYSCALL_ABI_64 Where 64-bit is always enabled on 64-bit kernels and ABI_32 is always enabled on 32-bit kernels. ABI_X32 enables the extra system calls that have 64-bit register width but a compact 32-bit memory model. ( I don't think we want CONFIG_ABI_16, because vm86 is really special, it's essentially an early x86 hypervisor implementation with no separate system call ABI. ) CONFIG_IA32_EMULATION is not just a double misnomer (it's not Intel specific and it's not emulation), it also does almost nothing useful, all it does is to enable a few options: select BINFMT_ELF select COMPAT_BINFMT_ELF select HAVE_UID16 and offers a legacy (aout) binformat. Note that the selects are wrong already: for example there's absolutely nothing wrong about an x32 environment without legacy HAVE_UID16 support. Instead of that we should simply introduce CONFIG_SYSCALL_ABI_* on x86 and implicitly select CONFIG_COMPAT, which is the generic kernel's 32-bit memory pointer model selector. (Question: do we have any architecture where compat isn't 32-bit with native being 64-bit?) Hm? Thanks, Ingo -- 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/