x86/entry: Create a home for the x86 entry code in arch/x86/entry/
Subsystems (3)
cover x86/entry: Create a home for the x86 entry code in arch/x86/entry/
So the x86 syscall/irq/etc. entry code is scattered in over 40 files all over the x86 architecture, making it hard to get a good overview of the code and its current status.
Move all the files to arch/x86/entry/.
This first step is as-is, no file names were changed - but the next step will be to organize things in a bit more maintainable fashion.
If there are no fundamental objections then I'll commit this to tip:x86/asm. (I've drained most of the pending patches to these files - but porting them should be easy in any case.)
Thanks,
Ingo
=========>
Ingo Molnar (7):
x86/asm/entry: Move entry_64.S and entry_32.S to arch/x86/entry/ x86/asm/entry: Move the compat syscall entry code to arch/x86/entry/ x86/asm/entry, x86/vdso: Move the vDSO code to arch/x86/entry/vdso/ x86/asm/entry: Move the 'thunk' functions to arch/x86/entry/ x86/asm/entry: Move arch/x86/include/asm/calling.h to arch/x86/entry/ x86/asm/entry: Move the arch/x86/syscalls/ definitions to arch/x86/entry/syscalls/ x86/asm/entry: Move the vsyscall code to arch/x86/entry/vsyscall/
MAINTAINERS | 2 +-
arch/x86/Kbuild | 5 ++++-
arch/x86/Makefile | 4 ++--
arch/x86/entry/Makefile | 10 ++++++++++
arch/x86/{include/asm => entry}/calling.h | 0
arch/x86/{kernel => entry}/entry_32.S | 0
arch/x86/{kernel => entry}/entry_64.S | 2 +-
arch/x86/{ia32 => entry}/ia32entry.S | 2 +-
arch/x86/{kernel => entry}/syscall_32.c | 0
arch/x86/{kernel => entry}/syscall_64.c | 0
arch/x86/{ => entry}/syscalls/Makefile | 4 ++--
arch/x86/{ => entry}/syscalls/syscall_32.tbl | 0
arch/x86/{ => entry}/syscalls/syscall_64.tbl | 0
arch/x86/{ => entry}/syscalls/syscallhdr.sh | 0
arch/x86/{ => entry}/syscalls/syscalltbl.sh | 0
arch/x86/{lib => entry}/thunk_32.S | 0
arch/x86/{lib => entry}/thunk_64.S | 2 +-
arch/x86/{ => entry}/vdso/.gitignore | 0
arch/x86/{ => entry}/vdso/Makefile | 0
arch/x86/{ => entry}/vdso/checkundef.sh | 0
arch/x86/{ => entry}/vdso/vclock_gettime.c | 0
arch/x86/{ => entry}/vdso/vdso-layout.lds.S | 0
arch/x86/{ => entry}/vdso/vdso-note.S | 0
arch/x86/{ => entry}/vdso/vdso.lds.S | 0
arch/x86/{ => entry}/vdso/vdso2c.c | 0
arch/x86/{ => entry}/vdso/vdso2c.h | 0
arch/x86/{ => entry}/vdso/vdso32-setup.c | 0
arch/x86/{ => entry}/vdso/vdso32/.gitignore | 0
arch/x86/{ => entry}/vdso/vdso32/int80.S | 0
arch/x86/{ => entry}/vdso/vdso32/note.S | 0
arch/x86/{ => entry}/vdso/vdso32/sigreturn.S | 0
arch/x86/{ => entry}/vdso/vdso32/syscall.S | 0
arch/x86/{ => entry}/vdso/vdso32/sysenter.S | 0
arch/x86/{ => entry}/vdso/vdso32/vclock_gettime.c | 0
arch/x86/{ => entry}/vdso/vdso32/vdso-fakesections.c | 0
arch/x86/{ => entry}/vdso/vdso32/vdso32.lds.S | 0
arch/x86/{ => entry}/vdso/vdsox32.lds.S | 0
arch/x86/{ => entry}/vdso/vgetcpu.c | 0
arch/x86/{ => entry}/vdso/vma.c | 0
arch/x86/entry/vsyscall/Makefile | 7 +++++++
arch/x86/{kernel => entry/vsyscall}/vsyscall_64.c | 0
arch/x86/{kernel => entry/vsyscall}/vsyscall_emu_64.S | 0
arch/x86/{kernel => entry/vsyscall}/vsyscall_gtod.c | 0
arch/x86/{kernel => entry/vsyscall}/vsyscall_trace.h | 2 +-
arch/x86/ia32/Makefile | 2 +-
arch/x86/kernel/Makefile | 5 +----
arch/x86/lib/Makefile | 1 -
scripts/checksyscalls.sh | 2 +-
48 files changed, 33 insertions(+), 17 deletions(-)
create mode 100644 arch/x86/entry/Makefile
rename arch/x86/{include/asm => entry}/calling.h (100%)
rename arch/x86/{kernel => entry}/entry_32.S (100%)
rename arch/x86/{kernel => entry}/entry_64.S (99%)
rename arch/x86/{ia32 => entry}/ia32entry.S (99%)
rename arch/x86/{kernel => entry}/syscall_32.c (100%)
rename arch/x86/{kernel => entry}/syscall_64.c (100%)
rename arch/x86/{ => entry}/syscalls/Makefile (95%)
rename arch/x86/{ => entry}/syscalls/syscall_32.tbl (100%)
rename arch/x86/{ => entry}/syscalls/syscall_64.tbl (100%)
rename arch/x86/{ => entry}/syscalls/syscallhdr.sh (100%)
rename arch/x86/{ => entry}/syscalls/syscalltbl.sh (100%)
rename arch/x86/{lib => entry}/thunk_32.S (100%)
rename arch/x86/{lib => entry}/thunk_64.S (98%)
rename arch/x86/{ => entry}/vdso/.gitignore (100%)
rename arch/x86/{ => entry}/vdso/Makefile (100%)
rename arch/x86/{ => entry}/vdso/checkundef.sh (100%)
rename arch/x86/{ => entry}/vdso/vclock_gettime.c (100%)
rename arch/x86/{ => entry}/vdso/vdso-layout.lds.S (100%)
rename arch/x86/{ => entry}/vdso/vdso-note.S (100%)
rename arch/x86/{ => entry}/vdso/vdso.lds.S (100%)
rename arch/x86/{ => entry}/vdso/vdso2c.c (100%)
rename arch/x86/{ => entry}/vdso/vdso2c.h (100%)
rename arch/x86/{ => entry}/vdso/vdso32-setup.c (100%)
rename arch/x86/{ => entry}/vdso/vdso32/.gitignore (100%)
rename arch/x86/{ => entry}/vdso/vdso32/int80.S (100%)
rename arch/x86/{ => entry}/vdso/vdso32/note.S (100%)
rename arch/x86/{ => entry}/vdso/vdso32/sigreturn.S (100%)
rename arch/x86/{ => entry}/vdso/vdso32/syscall.S (100%)
rename arch/x86/{ => entry}/vdso/vdso32/sysenter.S (100%)
rename arch/x86/{ => entry}/vdso/vdso32/vclock_gettime.c (100%)
rename arch/x86/{ => entry}/vdso/vdso32/vdso-fakesections.c (100%)
rename arch/x86/{ => entry}/vdso/vdso32/vdso32.lds.S (100%)
rename arch/x86/{ => entry}/vdso/vdsox32.lds.S (100%)
rename arch/x86/{ => entry}/vdso/vgetcpu.c (100%)
rename arch/x86/{ => entry}/vdso/vma.c (100%)
create mode 100644 arch/x86/entry/vsyscall/Makefile
rename arch/x86/{kernel => entry/vsyscall}/vsyscall_64.c (100%)
rename arch/x86/{kernel => entry/vsyscall}/vsyscall_emu_64.S (100%)
rename arch/x86/{kernel => entry/vsyscall}/vsyscall_gtod.c (100%)
rename arch/x86/{kernel => entry/vsyscall}/vsyscall_trace.h (89%)Signature · 1 line
2.1.4
PATCH 1/7 x86/asm/entry: Move entry_64.S and entry_32.S to arch/x86/entry/
Create a new directory hierarchy for the low level x86 entry code:
arch/x86/entry/*
This will host all the low level glue that is currently scattered all across arch/x86/.
Start with entry_64.S and entry_32.S.
---
arch/x86/Kbuild | 3 +++
arch/x86/entry/Makefile | 4 ++++
arch/x86/{kernel => entry}/entry_32.S | 0
arch/x86/{kernel => entry}/entry_64.S | 0
arch/x86/kernel/Makefile | 2 +-
5 files changed, 8 insertions(+), 1 deletion(-)arch/x86/Kbuild +3 -0
@@ -1,3 +1,6 @@ + +obj-y += entry/ + obj-$(CONFIG_KVM) += kvm/ # Xen paravirtualization support
arch/x86/entry/Makefile new file +4 -0
@@ -0,0 +1,4 @@ +# +# Makefile for the x86 low level entry code +# +obj-y := entry_$(BITS).o
arch/x86/entry/entry_32.S renamed from arch/x86/kernel/entry_32.S +0 -0
arch/x86/entry/entry_64.S renamed from arch/x86/kernel/entry_64.S +0 -0
arch/x86/kernel/Makefile +1 -1
@@ -22,7 +22,7 @@ KASAN_SANITIZE_dumpstack_$(BITS).o := n CFLAGS_irq.o := -I$(src)/../include/asm/trace -obj-y := process_$(BITS).o signal.o entry_$(BITS).o +obj-y := process_$(BITS).o signal.o obj-y += traps.o irq.o irq_$(BITS).o dumpstack_$(BITS).o obj-y += time.o ioport.o ldt.o dumpstack.o nmi.o obj-y += setup.o x86_init.o i8259.o irqinit.o jump_label.o
Signature · 1 line
2.1.4
PATCH 2/7 x86/asm/entry: Move the compat syscall entry code to arch/x86/entry/
In reply to Ingo MolnarMove the ia32entry.S file over into arch/x86/entry/.
---
arch/x86/entry/Makefile | 5 ++++-
arch/x86/{ia32 => entry}/ia32entry.S | 0
arch/x86/ia32/Makefile | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)arch/x86/entry/Makefile +4 -1
@@ -1,4 +1,7 @@ # # Makefile for the x86 low level entry code # -obj-y := entry_$(BITS).o +obj-y := entry_$(BITS).o + +obj-$(CONFIG_IA32_EMULATION) += ia32entry.o +
arch/x86/entry/ia32entry.S renamed from arch/x86/ia32/ia32entry.S +0 -0
arch/x86/ia32/Makefile +1 -1
@@ -2,7 +2,7 @@ # Makefile for the ia32 kernel emulation subsystem. # -obj-$(CONFIG_IA32_EMULATION) := ia32entry.o sys_ia32.o ia32_signal.o +obj-$(CONFIG_IA32_EMULATION) := sys_ia32.o ia32_signal.o obj-$(CONFIG_IA32_AOUT) += ia32_aout.o
Signature · 1 line
2.1.4
Re: [PATCH 2/7] x86/asm/entry: Move the compat syscall entry code to arch/x86/entry/
Quoted 1 line · Ingo Molnar
Move the
ia32entry.Sfile over intoarch/x86/entry/.
I think we should also rename it to compat_entry.S or something. ia32entry sounds suspiciously like 32-bit code.
--Andy
Re: [PATCH 2/7] x86/asm/entry: Move the compat syscall entry code to arch/x86/entry/
Quoted 5 lines · Andy Lutomirski
Quoted 1 line · Ingo Molnar
Move the
ia32entry.Sfile over intoarch/x86/entry/.I think we should also rename it to
compat_entry.Sor something. ia32entry sounds suspiciously like 32-bit code.
Absolutely, I alluded to that in the 0/7 description, but wanted to get the 'plain' movement done as a first step.
Thanks,
Ingo
PATCH 3/7 x86/asm/entry, x86/vdso: Move the vDSO code to arch/x86/entry/vdso/
In reply to Ingo Molnar---
MAINTAINERS | 2 +-
arch/x86/Kbuild | 2 +-
arch/x86/Makefile | 2 +-
arch/x86/entry/Makefile | 2 ++
arch/x86/{ => entry}/vdso/.gitignore | 0
arch/x86/{ => entry}/vdso/Makefile | 0
arch/x86/{ => entry}/vdso/checkundef.sh | 0
arch/x86/{ => entry}/vdso/vclock_gettime.c | 0
arch/x86/{ => entry}/vdso/vdso-layout.lds.S | 0
arch/x86/{ => entry}/vdso/vdso-note.S | 0
arch/x86/{ => entry}/vdso/vdso.lds.S | 0
arch/x86/{ => entry}/vdso/vdso2c.c | 0
arch/x86/{ => entry}/vdso/vdso2c.h | 0
arch/x86/{ => entry}/vdso/vdso32-setup.c | 0
arch/x86/{ => entry}/vdso/vdso32/.gitignore | 0
arch/x86/{ => entry}/vdso/vdso32/int80.S | 0
arch/x86/{ => entry}/vdso/vdso32/note.S | 0
arch/x86/{ => entry}/vdso/vdso32/sigreturn.S | 0
arch/x86/{ => entry}/vdso/vdso32/syscall.S | 0
arch/x86/{ => entry}/vdso/vdso32/sysenter.S | 0
arch/x86/{ => entry}/vdso/vdso32/vclock_gettime.c | 0
arch/x86/{ => entry}/vdso/vdso32/vdso-fakesections.c | 0
arch/x86/{ => entry}/vdso/vdso32/vdso32.lds.S | 0
arch/x86/{ => entry}/vdso/vdsox32.lds.S | 0
arch/x86/{ => entry}/vdso/vgetcpu.c | 0
arch/x86/{ => entry}/vdso/vma.c | 0
26 files changed, 5 insertions(+), 3 deletions(-)MAINTAINERS +1 -1
@@ -10892,7 +10892,7 @@ M: Andy Lutomirski <[email protected]> L: [email protected] T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/vdso S: Maintained -F: arch/x86/vdso/ +F: arch/x86/entry/vdso/ XC2028/3028 TUNER DRIVER M: Mauro Carvalho Chehab <[email protected]>
arch/x86/Kbuild +1 -1
@@ -14,7 +14,7 @@ obj-y += kernel/ obj-y += mm/ obj-y += crypto/ -obj-y += vdso/ + obj-$(CONFIG_IA32_EMULATION) += ia32/ obj-y += platform/
arch/x86/Makefile +1 -1
@@ -244,7 +244,7 @@ PHONY += install PHONY += vdso_install vdso_install: - $(Q)$(MAKE) $(build)=arch/x86/vdso $@ + $(Q)$(MAKE) $(build)=arch/x86/entry/vdso $@ archclean: $(Q)rm -rf $(objtree)/arch/i386
arch/x86/entry/Makefile +2 -0
@@ -3,5 +3,7 @@ # obj-y := entry_$(BITS).o +obj-y += vdso/ + obj-$(CONFIG_IA32_EMULATION) += ia32entry.o
arch/x86/entry/vdso/.gitignore renamed from arch/x86/vdso/.gitignore +0 -0
arch/x86/entry/vdso/Makefile renamed from arch/x86/vdso/Makefile +0 -0
arch/x86/entry/vdso/checkundef.sh renamed from arch/x86/vdso/checkundef.sh +0 -0
arch/x86/entry/vdso/vclock_gettime.c renamed from arch/x86/vdso/vclock_gettime.c +0 -0
arch/x86/entry/vdso/vdso-layout.lds.S renamed from arch/x86/vdso/vdso-layout.lds.S +0 -0
arch/x86/entry/vdso/vdso-note.S renamed from arch/x86/vdso/vdso-note.S +0 -0
arch/x86/entry/vdso/vdso.lds.S renamed from arch/x86/vdso/vdso.lds.S +0 -0
arch/x86/entry/vdso/vdso2c.c renamed from arch/x86/vdso/vdso2c.c +0 -0
arch/x86/entry/vdso/vdso2c.h renamed from arch/x86/vdso/vdso2c.h +0 -0
arch/x86/entry/vdso/vdso32-setup.c renamed from arch/x86/vdso/vdso32-setup.c +0 -0
arch/x86/entry/vdso/vdso32/.gitignore renamed from arch/x86/vdso/vdso32/.gitignore +0 -0
arch/x86/entry/vdso/vdso32/int80.S renamed from arch/x86/vdso/vdso32/int80.S +0 -0
arch/x86/entry/vdso/vdso32/note.S renamed from arch/x86/vdso/vdso32/note.S +0 -0
arch/x86/entry/vdso/vdso32/sigreturn.S renamed from arch/x86/vdso/vdso32/sigreturn.S +0 -0
arch/x86/entry/vdso/vdso32/syscall.S renamed from arch/x86/vdso/vdso32/syscall.S +0 -0
arch/x86/entry/vdso/vdso32/sysenter.S renamed from arch/x86/vdso/vdso32/sysenter.S +0 -0
arch/x86/entry/vdso/vdso32/vclock_gettime.c renamed from arch/x86/vdso/vdso32/vclock_gettime.c +0 -0
arch/x86/entry/vdso/vdso32/vdso-fakesections.c renamed from arch/x86/vdso/vdso32/vdso-fakesections.c +0 -0
arch/x86/entry/vdso/vdso32/vdso32.lds.S renamed from arch/x86/vdso/vdso32/vdso32.lds.S +0 -0
arch/x86/entry/vdso/vdsox32.lds.S renamed from arch/x86/vdso/vdsox32.lds.S +0 -0
arch/x86/entry/vdso/vgetcpu.c renamed from arch/x86/vdso/vgetcpu.c +0 -0
arch/x86/entry/vdso/vma.c renamed from arch/x86/vdso/vma.c +0 -0
Signature · 1 line
2.1.4
Re: [PATCH 3/7] x86/asm/entry, x86/vdso: Move the vDSO code to arch/x86/entry/vdso/
2015-06-03 9:59 GMT-07:00 Ingo Molnar <[email protected]>:
Quoted 10 lines
Cc Borislav Petkov <[email protected]>Cc H. Peter Anvin <[email protected]>Cc Linus Torvalds <[email protected]>Cc Thomas Gleixner <[email protected]>Cc Andy Lutomirski <[email protected]>Cc Denys Vlasenko <[email protected]>Cc Brian Gerst <[email protected]>Cc Peter Zijlstra <[email protected]>Signed-off-by Ingo Molnar <[email protected]>
I'm with hpa here. The vdso isn't really entry code.
--Andy
PATCH 4/7 x86/asm/entry: Move the 'thunk' functions to arch/x86/entry/
In reply to Ingo MolnarThese are all calling x86 entry code functions, so move them close to other entry code.
Change lib-y to obj-y: there's no real difference between the two as we don't really drop any of them during the linking stage, and obj-y is the more common approach for core kernel object code.
---
arch/x86/entry/Makefile | 3 +--
arch/x86/{lib => entry}/thunk_32.S | 0
arch/x86/{lib => entry}/thunk_64.S | 0
arch/x86/lib/Makefile | 1 -
4 files changed, 1 insertion(+), 3 deletions(-)arch/x86/entry/Makefile +1 -2
@@ -1,8 +1,7 @@ # # Makefile for the x86 low level entry code # -obj-y := entry_$(BITS).o - +obj-y := entry_$(BITS).o thunk_$(BITS).o obj-y += vdso/ obj-$(CONFIG_IA32_EMULATION) += ia32entry.o
arch/x86/entry/thunk_32.S renamed from arch/x86/lib/thunk_32.S +0 -0
arch/x86/entry/thunk_64.S renamed from arch/x86/lib/thunk_64.S +0 -0
arch/x86/lib/Makefile +0 -1
@@ -17,7 +17,6 @@ clean-files := inat-tables.c obj-$(CONFIG_SMP) += msr-smp.o cache-smp.o lib-y := delay.o misc.o cmdline.o -lib-y += thunk_$(BITS).o lib-y += usercopy_$(BITS).o usercopy.o getuser.o putuser.o lib-y += memcpy_$(BITS).o lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
Signature · 1 line
2.1.4
PATCH 5/7 x86/asm/entry: Move arch/x86/include/asm/calling.h to arch/x86/entry/
In reply to Ingo Molnarasm/calling.h is private to the entry code, make this more apparent by moving it to the new arch/x86/entry/ directory.
---
arch/x86/{include/asm => entry}/calling.h | 0
arch/x86/entry/entry_64.S | 2 +-
arch/x86/entry/ia32entry.S | 2 +-
arch/x86/entry/thunk_64.S | 2 +-
4 files changed, 3 insertions(+), 3 deletions(-)arch/x86/entry/calling.h renamed from arch/x86/include/asm/calling.h +0 -0
arch/x86/entry/entry_64.S +1 -1
@@ -28,7 +28,7 @@ #include <asm/segment.h> #include <asm/cache.h> #include <asm/errno.h> -#include <asm/calling.h> +#include "calling.h" #include <asm/asm-offsets.h> #include <asm/msr.h> #include <asm/unistd.h>
arch/x86/entry/ia32entry.S +1 -1
@@ -4,7 +4,7 @@ * Copyright 2000-2002 Andi Kleen, SuSE Labs. */ -#include <asm/calling.h> +#include "calling.h" #include <asm/asm-offsets.h> #include <asm/current.h> #include <asm/errno.h>
arch/x86/entry/thunk_64.S +1 -1
@@ -6,7 +6,7 @@ * Subject to the GNU public license, v.2. No warranty of any kind. */ #include <linux/linkage.h> -#include <asm/calling.h> +#include "calling.h" #include <asm/asm.h> /* rdi: arg1 ... normal C conventions. rax is saved/restored. */
Signature · 1 line
2.1.4
PATCH 6/7 x86/asm/entry: Move the arch/x86/syscalls/ definitions to arch/x86/entry/syscalls/
In reply to Ingo MolnarThe build time generated syscall definitions are entry code related, move them into the arch/x86/entry/ directory.
---
arch/x86/Makefile | 2 +-
arch/x86/{ => entry}/syscalls/Makefile | 4 ++--
arch/x86/{ => entry}/syscalls/syscall_32.tbl | 0
arch/x86/{ => entry}/syscalls/syscall_64.tbl | 0
arch/x86/{ => entry}/syscalls/syscallhdr.sh | 0
arch/x86/{ => entry}/syscalls/syscalltbl.sh | 0
scripts/checksyscalls.sh | 2 +-
7 files changed, 4 insertions(+), 4 deletions(-)arch/x86/Makefile +1 -1
@@ -181,7 +181,7 @@ archscripts: scripts_basic # Syscall table generation archheaders: - $(Q)$(MAKE) $(build)=arch/x86/syscalls all + $(Q)$(MAKE) $(build)=arch/x86/entry/syscalls all archprepare: ifeq ($(CONFIG_KEXEC_FILE),y)
arch/x86/entry/syscalls/Makefile renamed from arch/x86/syscalls/Makefile +2 -2
@@ -1,5 +1,5 @@ -out := $(obj)/../include/generated/asm -uapi := $(obj)/../include/generated/uapi/asm +out := $(obj)/../../include/generated/asm +uapi := $(obj)/../../include/generated/uapi/asm # Create output directory if not already present _dummy := $(shell [ -d '$(out)' ] || mkdir -p '$(out)') \
arch/x86/entry/syscalls/syscall_32.tbl renamed from arch/x86/syscalls/syscall_32.tbl +0 -0
arch/x86/entry/syscalls/syscall_64.tbl renamed from arch/x86/syscalls/syscall_64.tbl +0 -0
arch/x86/entry/syscalls/syscallhdr.sh renamed from arch/x86/syscalls/syscallhdr.sh +0 -0
arch/x86/entry/syscalls/syscalltbl.sh renamed from arch/x86/syscalls/syscalltbl.sh +0 -0
scripts/checksyscalls.sh +1 -1
@@ -212,5 +212,5 @@ EOF ) } -(ignore_list && syscall_list $(dirname $0)/../arch/x86/syscalls/syscall_32.tbl) | \ +(ignore_list && syscall_list $(dirname $0)/../arch/x86/entry/syscalls/syscall_32.tbl) | \ $* -E -x c - > /dev/null
Signature · 1 line
2.1.4
PATCH 7/7 x86/asm/entry: Move the vsyscall code to arch/x86/entry/vsyscall/
In reply to Ingo MolnarThe vsyscall code is entry code too, so move it to arch/x86/entry/vsyscall/.
---
arch/x86/entry/Makefile | 6 ++++--
arch/x86/{kernel => entry}/syscall_32.c | 0
arch/x86/{kernel => entry}/syscall_64.c | 0
arch/x86/entry/vsyscall/Makefile | 7 +++++++
arch/x86/{kernel => entry/vsyscall}/vsyscall_64.c | 0
arch/x86/{kernel => entry/vsyscall}/vsyscall_emu_64.S | 0
arch/x86/{kernel => entry/vsyscall}/vsyscall_gtod.c | 0
arch/x86/{kernel => entry/vsyscall}/vsyscall_trace.h | 2 +-
arch/x86/kernel/Makefile | 3 ---
9 files changed, 12 insertions(+), 6 deletions(-)arch/x86/entry/Makefile +4 -2
@@ -1,8 +1,10 @@ # # Makefile for the x86 low level entry code # -obj-y := entry_$(BITS).o thunk_$(BITS).o +obj-y := entry_$(BITS).o thunk_$(BITS).o syscall_$(BITS).o + obj-y += vdso/ +obj-y += vsyscall/ -obj-$(CONFIG_IA32_EMULATION) += ia32entry.o +obj-$(CONFIG_IA32_EMULATION) += ia32entry.o syscall_32.o
arch/x86/entry/syscall_32.c renamed from arch/x86/kernel/syscall_32.c +0 -0
arch/x86/entry/syscall_64.c renamed from arch/x86/kernel/syscall_64.c +0 -0
arch/x86/entry/vsyscall/Makefile new file +7 -0
@@ -0,0 +1,7 @@ +# +# Makefile for the x86 low level vsyscall code +# +obj-y := vsyscall_gtod.o + +obj-$(CONFIG_X86_VSYSCALL_EMULATION) += vsyscall_64.o vsyscall_emu_64.o +
arch/x86/entry/vsyscall/vsyscall_64.c renamed from arch/x86/kernel/vsyscall_64.c +0 -0
arch/x86/entry/vsyscall/vsyscall_emu_64.S renamed from arch/x86/kernel/vsyscall_emu_64.S +0 -0
arch/x86/entry/vsyscall/vsyscall_gtod.c renamed from arch/x86/kernel/vsyscall_gtod.c +0 -0
arch/x86/entry/vsyscall/vsyscall_trace.h renamed from arch/x86/kernel/vsyscall_trace.h +1 -1
@@ -24,6 +24,6 @@ TRACE_EVENT(emulate_vsyscall,#endif #undef TRACE_INCLUDE_PATH -#define TRACE_INCLUDE_PATH ../../arch/x86/kernel +#define TRACE_INCLUDE_PATH ../../arch/x86/entry/vsyscall/ #define TRACE_INCLUDE_FILE vsyscall_trace#include <trace/define_trace.h>
arch/x86/kernel/Makefile +0 -3
@@ -31,9 +31,6 @@ obj-y += probe_roms.o obj-$(CONFIG_X86_32) += i386_ksyms_32.o obj-$(CONFIG_X86_64) += sys_x86_64.o x8664_ksyms_64.o obj-$(CONFIG_X86_64) += mcount_64.o -obj-y += syscall_$(BITS).o vsyscall_gtod.o -obj-$(CONFIG_IA32_EMULATION) += syscall_32.o -obj-$(CONFIG_X86_VSYSCALL_EMULATION) += vsyscall_64.o vsyscall_emu_64.o obj-$(CONFIG_X86_ESPFIX64) += espfix_64.o obj-$(CONFIG_SYSFS) += ksysfs.o obj-y += bootflag.o e820.o
Signature · 1 line
2.1.4
H. Peter Anvin
reviewerQuoted 5 lines · Ingo Molnar
So the x86 syscall/irq/etc. entry code is scattered in over 40 files all over the x86 architecture, making it hard to get a good overview of the code and its current status.
Quoted 8 lines
Move all the files to
arch/x86/entry/.This first step is as-is, no file names were changed - but the next step will be to organize things in a bit more maintainable fashion.
If there are no fundamental objections then I'll commit this to tip:x86/asm. (I've drained most of the pending patches to these files - but porting them should be easy in any case.)
I would prefer if it was made a separate topic.
I like the patch set (and you can add my Acked-by:) *except* 7/7, and the reason for that is that it really isn't entry code, it is user space code.
I also dislike deep directory hierarchies in general, unless it really be avoided, like boot/ or realmode/.
-hpa
Quoted 2 lines · H. Peter Anvin
I like the patch set (and you can add my Acked-by:) *except* 7/7, and the reason for that is that it really isn't entry code, it is user space code.
Well, I think arch/x86/entry/ should be a broader category for all things entry
code: and the vsyscall code is closely related to the syscall entry/exit code so it's in a better place there than just being in the generic arch/x86/kernel/ directory.
I kept it separate in arch/x86/entry/vsyscall/ so it doesn't mix with other entry code.
Thanks,
Ingo
Quoted 6 lines · Ingo Molnar
Quoted 2 lines · H. Peter Anvin
I like the patch set (and you can add my Acked-by:) *except* 7/7, and the reason for that is that it really isn't entry code, it is user space code.
Quoted 7 lines
Well, I think
arch/x86/entry/should be a broader category for all things entry
code: and the vsyscall code is closely related to the syscall entry/exit code so it's in a better place there than just being in the genericarch/x86/kernel/directory.I kept it separate in
arch/x86/entry/vsyscall/so it doesn't mix with other entry code.
...and my reading comprehension is way off this morning. You already called it arch/x86/entry, so there was no reason for me to suggest that :)
Anyway, arch/x86/entry/vdso isn't so bad. It's just a bit odd sounding to me.
--Andy
Quoted 4 lines
Thanks,
Ingo
Signature · 2 lines
Andy Lutomirski AMA Capital Management, LLC
Quoted 12 lines · Andy Lutomirski
Quoted 11 lines · Ingo Molnar
Quoted 2 lines · H. Peter Anvin
I like the patch set (and you can add my Acked-by:) *except* 7/7, and the reason for that is that it really isn't entry code, it is user space code.
Well, I think
arch/x86/entry/should be a broader category for all things entry
code: and the vsyscall code is closely related to the syscall entry/exit code so it's in a better place there than just being in the genericarch/x86/kernel/directory.
Quoted 7 lines
Quoted 2 lines
I kept it separate in
arch/x86/entry/vsyscall/so it doesn't mix with other entry code....and my reading comprehension is way off this morning. You already called it
arch/x86/entry, so there was no reason for me to suggest that :)Anyway,
arch/x86/entry/vdsoisn't so bad. It's just a bit odd sounding to me.
We could make it arch/x86/sys/? Sounds a bit too generic though.
Didn't want to limit it to system calls only, because there's various other entry methods (irqs, traps, NMI, etc.) that we want to handle in a coherent fashion. [ Which you are intimately aware of ;-) ]
Thanks,
Ingo
Quoted 21 lines · Ingo Molnar
Quoted 18 lines · Andy Lutomirski
Quoted 6 lines · Ingo Molnar
Quoted 2 lines · H. Peter Anvin
I like the patch set (and you can add my Acked-by:) *except* 7/7, and the reason for that is that it really isn't entry code, it is user space code.
Quoted 7 lines
Well, I think
arch/x86/entry/should be a broader category for all things entry
code: and the vsyscall code is closely related to the syscall entry/exit code so it's in a better place there than just being in the genericarch/x86/kernel/directory.I kept it separate in
arch/x86/entry/vsyscall/so it doesn't mix with other entry code....and my reading comprehension is way off this morning. You already called it
arch/x86/entry, so there was no reason for me to suggest that :)
Quoted 7 lines
Quoted 1 line
Anyway,
arch/x86/entry/vdsoisn't so bad. It's just a bit odd sounding to me.We could make it
arch/x86/sys/? Sounds a bit too generic though.Didn't want to limit it to system calls only, because there's various other entry methods (irqs, traps, NMI, etc.) that we want to handle in a coherent fashion. [ Which you are intimately aware of ;-) ]
Another tweak would be to move the kernel side entry code into arch/x86/entry/system/ or so, to create the following organization:
arch/x86/entry: all things entry methods
arch/x86/entry/system/: system/kernel mode entry code
arch/x86/entry/vdso/: user mode entry code
arch/x86/entry/vsyscall/: [legacy vsyscall entry code]
arch/x86/entry/syscalls/: build-time syscall table generation code
My primary goal is to have them all close to each other, so that we can have better structure, more coherency and easier overview. The names are negotiable, the concept is not ;-)
Thanks,
Ingo
Quoted 41 lines · Ingo Molnar
Quoted 21 lines · Ingo Molnar
Quoted 18 lines · Andy Lutomirski
Quoted 6 lines · Ingo Molnar
Quoted 2 lines · H. Peter Anvin
I like the patch set (and you can add my Acked-by:) *except* 7/7, and the reason for that is that it really isn't entry code, it is user space code.
Quoted 7 lines
Well, I think
arch/x86/entry/should be a broader category for all things entry
code: and the vsyscall code is closely related to the syscall entry/exit code so it's in a better place there than just being in the genericarch/x86/kernel/directory.I kept it separate in
arch/x86/entry/vsyscall/so it doesn't mix with other entry code....and my reading comprehension is way off this morning. You already called it
arch/x86/entry, so there was no reason for me to suggest that :)Quoted 7 lines
Quoted 1 line
Anyway,
arch/x86/entry/vdsoisn't so bad. It's just a bit odd sounding to me.We could make it
arch/x86/sys/? Sounds a bit too generic though.Didn't want to limit it to system calls only, because there's various other entry methods (irqs, traps, NMI, etc.) that we want to handle in a coherent fashion. [ Which you are intimately aware of ;-) ]
Another tweak would be to move the kernel side entry code into
arch/x86/entry/system/or so, to create the following organization:
arch/x86/entry: all things entry methods
arch/x86/entry/system/: system/kernel mode entry code
arch/x86/entry/vdso/: user mode entry code
arch/x86/entry/vsyscall/: [legacy vsyscall entry code]
Quoted 5 lines
arch/x86/entry/syscalls/: build-time syscall table generation codeMy primary goal is to have them all close to each other, so that we can have better structure, more coherency and easier overview. The names are negotiable, the concept is not ;-)
I think I like the approach in the patches you sent better.
Once this is in, I'll rebase my code movement change and send it, although I probably won't call the result arch/x86/entry/entry.c :) And then it'll be back to grumbling at context tracking.
--Andy
Quoted 42 lines · Andy Lutomirski
Quoted 41 lines · Ingo Molnar
Quoted 21 lines · Ingo Molnar
Quoted 18 lines · Andy Lutomirski
Quoted 6 lines · Ingo Molnar
Quoted 2 lines · H. Peter Anvin
I like the patch set (and you can add my Acked-by:) *except* 7/7, and the reason for that is that it really isn't entry code, it is user space code.
Quoted 7 lines
Well, I think
arch/x86/entry/should be a broader category for all things entry
code: and the vsyscall code is closely related to the syscall entry/exit code so it's in a better place there than just being in the genericarch/x86/kernel/directory.I kept it separate in
arch/x86/entry/vsyscall/so it doesn't mix with other entry code....and my reading comprehension is way off this morning. You already called it
arch/x86/entry, so there was no reason for me to suggest that :)Quoted 7 lines
Quoted 1 line
Anyway,
arch/x86/entry/vdsoisn't so bad. It's just a bit odd sounding to me.We could make it
arch/x86/sys/? Sounds a bit too generic though.Didn't want to limit it to system calls only, because there's various other entry methods (irqs, traps, NMI, etc.) that we want to handle in a coherent fashion. [ Which you are intimately aware of ;-) ]
Another tweak would be to move the kernel side entry code into
arch/x86/entry/system/or so, to create the following organization:
arch/x86/entry: all things entry methods
arch/x86/entry/system/: system/kernel mode entry code
arch/x86/entry/vdso/: user mode entry code
arch/x86/entry/vsyscall/: [legacy vsyscall entry code]
Quoted 7 lines
Quoted 5 lines
arch/x86/entry/syscalls/: build-time syscall table generation codeMy primary goal is to have them all close to each other, so that we can have better structure, more coherency and easier overview. The names are negotiable, the concept is not ;-)
I think I like the approach in the patches you sent better.
Ok.
Quoted 1 line
Once this is in, I'll rebase my code movement change and send it,
Sounds good to me!
Quoted 1 line
although I probably won't call the result
arch/x86/entry/entry.c:)
A few naming suggestions:
arch/x86/entry/core.c
arch/x86/entry/sys.c
arch/x86/entry/kernel.c
;-)
Note ... I'd love to split up the various entry methods into separate files - but will do that only on top of your C based bits.
And once that is done, the names of those files will be obvious and clean:
arch/x86/entry/syscall.c
arch/x86/entry/irq.c
arch/x86/entry/traps.c
arch/x86/entry/nmi.c
arch/x86/entry/et.c
Quoted 1 line
And then it'll be back to grumbling at context tracking.
Uh oh ...
Thanks,
Ingo
Quoted 21 lines · Ingo Molnar
Quoted 18 lines · Andy Lutomirski
Quoted 6 lines · Ingo Molnar
Quoted 2 lines · H. Peter Anvin
I like the patch set (and you can add my Acked-by:) *except* 7/7, and the reason for that is that it really isn't entry code, it is user space code.
Quoted 7 lines
Well, I think
arch/x86/entry/should be a broader category for all things entry
code: and the vsyscall code is closely related to the syscall entry/exit code so it's in a better place there than just being in the genericarch/x86/kernel/directory.I kept it separate in
arch/x86/entry/vsyscall/so it doesn't mix with other entry code....and my reading comprehension is way off this morning. You already called it
arch/x86/entry, so there was no reason for me to suggest that :)
Quoted 8 lines
Quoted 1 line
Anyway,
arch/x86/entry/vdsoisn't so bad. It's just a bit odd sounding to me.We could make it
arch/x86/sys/? Sounds a bit too generic though.Didn't want to limit it to system calls only, because there's various other entry methods (irqs, traps, NMI, etc.) that we want to handle in a coherent fashion. [ Which you are intimately aware of ;-) ]
I'm convinced. If "entry" means entry into code provided by the kernel as opposed to entry via hardware-provided entry mechanism, then the vdso is indeed a pile of entries into the kernel.
--Andy
Quoted 3 lines
Thanks,
Ingo
Signature · 2 lines
Andy Lutomirski AMA Capital Management, LLC
H. Peter Anvin
reviewerQuoted 5 lines · Andy Lutomirski
I'm convinced. If "entry" means entry into code provided by the kernel as opposed to entry via hardware-provided entry mechanism, then the vdso is indeed a pile of entries into the kernel.
No, it isn't. It is user space code provided by the kernel. It is a very different beast, and this is highly and unnecessarily confusing. I am thrilled we finally have managed to get the vdso code separated out, this just muddles the situation.
-hpa
H. Peter Anvin
reviewerQuoted 7 lines · H. Peter Anvin
Quoted 5 lines · Andy Lutomirski
I'm convinced. If "entry" means entry into code provided by the kernel as opposed to entry via hardware-provided entry mechanism, then the vdso is indeed a pile of entries into the kernel.
Quoted 5 lines
No, it isn't. It is user space code provided by the kernel. It is a very different beast, and this is highly and unnecessarily confusing. I am thrilled we finally have managed to get the vdso code separated out, this just muddles the situation.
So let me clarify this: vdso code is really a kind of system calls, that just happen to be executed in user space, thus *bypassing* kernel entry.
We don't want to put all the system call code (or even the x86-specific
ones) in entry/ as that would completely eliminate the point and we have once again re-invented the kernel/ catch-all.
-hpa
Quoted 9 lines · Ingo Molnar
So the x86 syscall/irq/etc. entry code is scattered in over 40 files all over the x86 architecture, making it hard to get a good overview of the code and its current status.
Move all the files to
arch/x86/entry/.This first step is as-is, no file names were changed - but the next step will be to organize things in a bit more maintainable fashion.
Sort of like this?
/me cringes at the impending rebase.
Anyway, I like this series except patch 7.
--Andy
Quoted 11 lines · Andy Lutomirski
Quoted 9 lines · Ingo Molnar
So the x86 syscall/irq/etc. entry code is scattered in over 40 files all over the x86 architecture, making it hard to get a good overview of the code and its current status.
Move all the files to
arch/x86/entry/.This first step is as-is, no file names were changed - but the next step will be to organize things in a bit more maintainable fashion.
Quoted 8 lines
Sort of like this?
/me cringes at the impending rebase.
Anyway, I like this series except patch 7.
I can't count. I mean all except patch 3 (the vdso one), not 7.
Although arch/x86/entry might be less of a mouthful.
Quoted 1 line
--Andy
Signature · 2 lines
Andy Lutomirski AMA Capital Management, LLC
Quoted 16 lines · Andy Lutomirski
Quoted 15 lines · Andy Lutomirski
Quoted 9 lines · Ingo Molnar
So the x86 syscall/irq/etc. entry code is scattered in over 40 files all over the x86 architecture, making it hard to get a good overview of the code and its current status.
Move all the files to
arch/x86/entry/.This first step is as-is, no file names were changed - but the next step will be to organize things in a bit more maintainable fashion.
Sort of like this?
Quoted 8 lines
Quoted 4 lines
/me cringes at the impending rebase.
Anyway, I like this series except patch 7.
I can't count. I mean all except patch 3 (the vdso one), not 7.
Although
arch/x86/entrymight be less of a mouthful.
So see my reply to hpa: it makes sense to collect all things system calls and other entry code in a single place, instead of having it scattered all around.
Its internal organization is kept intact, so the vDSO code isn't mixed with other bits.
Thanks,
Ingo
H. Peter Anvin
reviewerQuoted 5 lines · Ingo Molnar
Quoted 5 lines
Quoted 3 lines
Anyway, I like this series except patch 7.
I can't count. I mean all except patch 3 (the vdso one), not 7.
Same here... erk.
Quoted 7 lines
Quoted 1 line
Although
arch/x86/entrymight be less of a mouthful.So see my reply to hpa: it makes sense to collect all things system calls and other entry code in a single place, instead of having it scattered all around.
Its internal organization is kept intact, so the vDSO code isn't mixed with other bits.
That really doesn't change the fact that it is a completely different beast, and putting it under entry/ is actively misleading. Having vdso/ as a separate top level is a good thing, I believe.
I really dislike deep hierarchies, as I said, because my experience has been that they are more confusing than they are helpful, especially over time. The arch-example of badness is of course arch/x86/kernel, which is a total catch-all, but
-hpa
Quoted 4 lines · H. Peter Anvin
I really dislike deep hierarchies, as I said, because my experience has been that they are more confusing than they are helpful, especially over time. The arch-example of badness is of course
arch/x86/kernel, which is a total catch-all, but
Well, directory hierarchy can certainly be overdone, but in general the Linux kernel has the exact opposite problem: too shallow directory organization due to two decades of organic growth.
We've been actively working over the last two years to improve the source code hierarchy gradually: kernel/rcu/, kernel/locking/, kernel/events/, kernel/sched/ and kernel/time/ are all examples of that process. It worked out pretty well IMHO.
This series actively depopulates various catch-all places such as arch/x86/kernel/ and arch/x86/lib/ and moves related code closer to each other.
The purpose of arch/x86/entry/ is:
- implementation of the high level runtime interfaces to enter/exit (call) the Linux kernel, both for hardware and for software defined ABIs.
Each of the files moved directly relate to these interfaces. It's not limited to kernel mode entries alone.
We could rename it to arch/x86/abi/, although that would be somewhat confusing I suspect because it's too generic a name?
Anyway, I pushed this out as it's a step forward and to not hold up ongoing asm work - we'll see how it works out in practice!
Thanks,
Ingo