I'm wondering what people think about this naming scheme:
entry_32.S # 32-bit binaries on 32-bit kernels
entry_64.S # 64-bit binaries on 64-bit kernels
entry_64_compat_32.S # 32-bit binaries on 64-bit kernels
Another option would be:
arch/x86/entry/sys_32.S
arch/x86/entry/sys_64.S
arch/x86/entry/sys_64_compat.S
?
Thanks,
Ingo
===
Ingo Molnar (1):
x86/asm/entry/64/compat: Rename ia32entry.S -> entry_64_compat_32.S
arch/x86/entry/Makefile | 2 +-
arch/x86/entry/entry_64.S | 2 +-
arch/x86/entry/{ia32entry.S => entry_64_compat_32.S} | 0
3 files changed, 2 insertions(+), 2 deletions(-)
rename arch/x86/entry/{ia32entry.S => entry_64_compat_32.S} (100%)
--
2.1.4
So we now have the following system entry code related
files, which define the following system call instruction
and other entry paths:
entry_32.S # 32-bit binaries on 32-bit kernels
entry_64.S # 64-bit binaries on 64-bit kernels
entry_64_compat_32.S # 32-bit binaries on 64-bit kernels
Cc: Alexei Starovoitov <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: Denys Vlasenko <[email protected]>
Cc: Frederic Weisbecker <[email protected]>
Cc: H. Peter Anvin <[email protected]>
Cc: Josh Triplett <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Steven Rostedt <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Will Drewry <[email protected]>
Cc: [email protected]
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/entry/Makefile | 2 +-
arch/x86/entry/entry_64.S | 2 +-
arch/x86/entry/{ia32entry.S => entry_64_compat_32.S} | 0
3 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/entry/Makefile b/arch/x86/entry/Makefile
index b93cce1c6bb2..c1e6f5406f9e 100644
--- a/arch/x86/entry/Makefile
+++ b/arch/x86/entry/Makefile
@@ -6,5 +6,5 @@ obj-y := entry_$(BITS).o thunk_$(BITS).o syscall_$(BITS).o
obj-y += vdso/
obj-y += vsyscall/
-obj-$(CONFIG_IA32_EMULATION) += ia32entry.o syscall_32.o
+obj-$(CONFIG_IA32_EMULATION) += entry_64_compat_32.o syscall_32.o
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 31770662b940..4cf3dd36aa0d 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -516,7 +516,7 @@ ENTRY(ret_from_fork)
/*
* By the time we get here, we have no idea whether our pt_regs,
* ti flags, and ti status came from the 64-bit SYSCALL fast path,
- * the slow path, or one of the ia32entry paths.
+ * the slow path, or one of the 32-bit compat paths.
* Use IRET code path to return, since it can safely handle
* all of the above.
*/
diff --git a/arch/x86/entry/ia32entry.S b/arch/x86/entry/entry_64_compat_32.S
similarity index 100%
rename from arch/x86/entry/ia32entry.S
rename to arch/x86/entry/entry_64_compat_32.S
--
2.1.4
On Fri, Jun 05, 2015 at 03:00:29PM +0200, Ingo Molnar wrote:
> I'm wondering what people think about this naming scheme:
>
> entry_32.S # 32-bit binaries on 32-bit kernels
> entry_64.S # 64-bit binaries on 64-bit kernels
> entry_64_compat_32.S # 32-bit binaries on 64-bit kernels
>
> Another option would be:
>
> arch/x86/entry/sys_32.S
> arch/x86/entry/sys_64.S
> arch/x86/entry/sys_64_compat.S
I like this one better because entry_64_compat_32 kinda has both bitness in
there and confuses me more.
Just my 2 ¢. :)
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
On Fri, Jun 5, 2015 at 9:00 AM, Ingo Molnar <[email protected]> wrote:
> So we now have the following system entry code related
> files, which define the following system call instruction
> and other entry paths:
>
> entry_32.S # 32-bit binaries on 32-bit kernels
> entry_64.S # 64-bit binaries on 64-bit kernels
> entry_64_compat_32.S # 32-bit binaries on 64-bit kernels
That's too long. How about just merging it into entry_64.S? That
could also allow moving some of the obscure macros from calling.h into
entry_64.S where they are more visible.
--
Brian Gerst
Call it sys if it is now only the system call entry points. Agreed with _64_compat too.
Breaking up these snarls of spaghetti assembly will be a blessing.
On June 5, 2015 6:37:14 AM PDT, Borislav Petkov <[email protected]> wrote:
>On Fri, Jun 05, 2015 at 03:00:29PM +0200, Ingo Molnar wrote:
>> I'm wondering what people think about this naming scheme:
>>
>> entry_32.S # 32-bit binaries on 32-bit
>kernels
>> entry_64.S # 64-bit binaries on 64-bit
>kernels
>> entry_64_compat_32.S # 32-bit binaries on 64-bit
>kernels
>>
>> Another option would be:
>>
>> arch/x86/entry/sys_32.S
>> arch/x86/entry/sys_64.S
>> arch/x86/entry/sys_64_compat.S
>
>I like this one better because entry_64_compat_32 kinda has both
>bitness in
>there and confuses me more.
>
>Just my 2 ¢. :)
--
Sent from my mobile phone. Please pardon brevity and lack of formatting.
On Fri, Jun 5, 2015 at 2:09 PM, H. Peter Anvin <[email protected]> wrote:
> Call it sys if it is now only the system call entry points. Agreed with _64_compat too.
>
> Breaking up these snarls of spaghetti assembly will be a blessing.
I'm not too picky about what we call it or whether we merge it with
entry_64.S. *However*, I think the file name should end in _64.S.
The whole arch/x86 tree is arranged such that files that end in _64.S
or _64.c are build for 64-bit kernels and not for 32-bit kernels. I
see no reason to deviate from that.
FWIW, I'm eventually planning to completely rewrite the compat entry
points to use the new (RFC patches coming in a week or two I hope!) C
exit code with opportunistic sysretl at the end. I'm guessing the
result will be about half the size of the current code, and it'll be
comprehensible to mere mortals.
--Andy
>
> On June 5, 2015 6:37:14 AM PDT, Borislav Petkov <[email protected]> wrote:
>>On Fri, Jun 05, 2015 at 03:00:29PM +0200, Ingo Molnar wrote:
>>> I'm wondering what people think about this naming scheme:
>>>
>>> entry_32.S # 32-bit binaries on 32-bit
>>kernels
>>> entry_64.S # 64-bit binaries on 64-bit
>>kernels
>>> entry_64_compat_32.S # 32-bit binaries on 64-bit
>>kernels
>>>
>>> Another option would be:
>>>
>>> arch/x86/entry/sys_32.S
>>> arch/x86/entry/sys_64.S
>>> arch/x86/entry/sys_64_compat.S
>>
>>I like this one better because entry_64_compat_32 kinda has both
>>bitness in
>>there and confuses me more.
>>
>>Just my 2 ¢. :)
>
> --
> Sent from my mobile phone. Please pardon brevity and lack of formatting.
--
Andy Lutomirski
AMA Capital Management, LLC
* Andy Lutomirski <[email protected]> wrote:
> On Fri, Jun 5, 2015 at 2:09 PM, H. Peter Anvin <[email protected]> wrote:
> > Call it sys if it is now only the system call entry points. Agreed with _64_compat too.
> >
> > Breaking up these snarls of spaghetti assembly will be a blessing.
>
> I'm not too picky about what we call it or whether we merge it with entry_64.S.
> *However*, I think the file name should end in _64.S. The whole arch/x86 tree is
> arranged such that files that end in _64.S or _64.c are build for 64-bit kernels
> and not for 32-bit kernels. I see no reason to deviate from that.
>
> FWIW, I'm eventually planning to completely rewrite the compat entry points to
> use the new (RFC patches coming in a week or two I hope!) C exit code with
> opportunistic sysretl at the end. I'm guessing the result will be about half
> the size of the current code, and it'll be comprehensible to mere mortals.
Ok, so I think the best is if I leave it alone for now: I've renamed it to
entry_64_compat.S as per Boris's and hpa's suggestion, but won't merge it into
entry_64.S (yet), let's see how your C conversion works out!
Thanks,
Ingo