Re: [PATCH] x86/asm/entry/32: Rename labels in INT 0x80 code path

[Ingo Molnar]

* Brian Gerst <brgerst@xxxxxxxxx> wrote:

> On Mon, Jun 8, 2015 at 1:35 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> >
> > * Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> >> On Jun 7, 2015 11:42 AM, "Denys Vlasenko" <dvlasenk@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/