utrace: remove exports
Subsystems (3)
PATCH 1/1 utrace: remove exports
All the exports in utrace are totally unused, and not really something I'd want modules to use anyway :)
arch/i386/kernel/ptrace.c +0 -1
@@ -729,7 +729,6 @@ const struct utrace_regset_view utrace_i .name = "i386", .e_machine = EM_386, .regsets = native_regsets, .n = ARRAY_SIZE(native_regsets) }; -EXPORT_SYMBOL_GPL (utrace_i386_native);#ifdef CONFIG_PTRACE static const struct ptrace_layout_segment i386_uarea[] = {
arch/ia64/ia32/sys_ia32.c +0 -1
@@ -2337,7 +2337,6 @@ const struct utrace_regset_view utrace_i .name = "i386", .e_machine = EM_386, .regsets = ia32_regsets, .n = ARRAY_SIZE(ia32_regsets) }; -EXPORT_SYMBOL_GPL (utrace_ia32_view);#ifdef CONFIG_PTRACE /*
arch/ia64/kernel/ptrace.c +0 -1
@@ -1547,7 +1547,6 @@ const struct utrace_regset_view utrace_i .e_machine = EM_IA_64, .regsets = native_regsets, .n = ARRAY_SIZE(native_regsets) }; -EXPORT_SYMBOL_GPL (utrace_ia64_native);#ifdef CONFIG_PTRACE
arch/powerpc/kernel/ptrace.c +0 -3
@@ -346,8 +346,6 @@ const struct utrace_regset_view utrace_p .name = UTS_MACHINE, .e_machine = ELF_ARCH, .regsets = native_regsets, .n = ARRAY_SIZE(native_regsets) }; -EXPORT_SYMBOL_GPL (utrace_ppc_native_view); -#ifdef CONFIG_PPC64 #include <linux/compat.h>
@@ -458,7 +456,6 @@ const struct utrace_regset_view utrace_p .name = "ppc", .e_machine = EM_PPC, .regsets = ppc32_regsets, .n = ARRAY_SIZE(ppc32_regsets) }; -EXPORT_SYMBOL_GPL (utrace_ppc32_view);#endif
arch/s390/kernel/ptrace.c +0 -3
@@ -315,8 +315,6 @@ const struct utrace_regset_view utrace_s .name = UTS_MACHINE, .e_machine = ELF_ARCH, .regsets = native_regsets, .n = ARRAY_SIZE(native_regsets) }; -EXPORT_SYMBOL_GPL (utrace_s390_native_view); -#ifdef CONFIG_COMPAT static int
@@ -564,7 +562,6 @@ const struct utrace_regset_view utrace_s .name = "s390", .e_machine = EM_S390, .regsets = s390_compat_regsets, .n = ARRAY_SIZE(s390_compat_regsets) }; -EXPORT_SYMBOL_GPL (utrace_s390_compat_view);#endif /* CONFIG_COMPAT */
arch/sparc64/kernel/ptrace.c +0 -2
@@ -258,7 +258,6 @@ const struct utrace_regset_view utrace_s .name = UTS_MACHINE, .e_machine = ELF_ARCH, .regsets = native_regsets, .n = ARRAY_SIZE(native_regsets) }; -EXPORT_SYMBOL_GPL (utrace_sparc64_native_view);#ifdef CONFIG_COMPAT
@@ -596,7 +595,6 @@ const struct utrace_regset_view utrace_s .name = "sparc", .e_machine = EM_SPARC, .regsets = sparc32_regsets, .n = ARRAY_SIZE(sparc32_regsets) }; -EXPORT_SYMBOL_GPL (utrace_sparc32_view);#endif /* CONFIG_COMPAT */
arch/x86_64/ia32/ptrace32.c +0 -2
@@ -596,8 +596,6 @@ const struct utrace_regset_view utrace_i .name = "i386", .e_machine = EM_386, .regsets = ia32_regsets, .n = ARRAY_SIZE(ia32_regsets) }; -EXPORT_SYMBOL_GPL (utrace_ia32_view); -#ifdef CONFIG_PTRACE /*
arch/x86_64/kernel/ptrace.c +0 -2
@@ -703,8 +703,6 @@ const struct utrace_regset_view utrace_x .name = "x86-64", .e_machine = EM_X86_64, .regsets = native_regsets, .n = ARRAY_SIZE(native_regsets) }; -EXPORT_SYMBOL_GPL (utrace_x86_64_native); -#ifdef CONFIG_PTRACE static const struct ptrace_layout_segment x86_64_uarea[] = {
kernel/utrace.c +1 -9
@@ -490,7 +490,6 @@ restart:return engine; } -EXPORT_SYMBOL_GPL (utrace_attach);/* * When an engine is detached, the target thread may still see it and make
@@ -700,8 +699,6 @@ utrace_detach(struct task_struct *targetreturn 0 ; } -EXPORT_SYMBOL_GPL (utrace_detach); -/* * Called with utrace->lock held.
@@ -900,8 +897,7 @@ restart: /* See below. */return ret; } -EXPORT_SYMBOL_GPL (utrace_set_flags); - +/* * While running an engine callback, no locks are held. * If a callback updates its engine's action state, then
@@ -1930,8 +1926,6 @@ utrace_inject_signal(struct task_structreturn ret; } -EXPORT_SYMBOL_GPL (utrace_inject_signal); -const struct utrace_regset * utrace_regset(struct task_struct *target,
@@ -1946,8 +1940,6 @@ utrace_regset(struct task_struct *targetreturn &view->regsets[which]; } -EXPORT_SYMBOL_GPL (utrace_regset); -/* * Return the task_struct for the task using ptrace on this one, or NULL.
Quoted 2 lines
All the exports in utrace are totally unused, and not really something I'd want modules to use anyway :)
Quoted 6 lines · Previously you
EXPORT_SYMBOL_GPL(utrace_attach);There is not modular user of this, so this and the other
utrace_functions should not be exported. Nor do I think that exporting such a low-level process control is nessecary a good idea, but we'll have to evaluate that if patches to add users show up.
If you remove the exports, just throw the whole thing away. The reason utrace exists is to be used by modules.
It's true that the only users around are some simple test and demo modules I've done, and some unfinished and experimental work such as uprobes. When useful things built on utrace get hashed out and in a functional state ready for general consumption, then it may be time to put them in the kernel tree. (All the work I'm aware of is pretty well public already, just not in any condition to be submitted.)
There is something of a chicken and egg problem here. In the current kernel, most people consider adding or enhancing a user debugging facility to be intractable. The intent of utrace is to make experimenting and developing in this area feasible. If it's not there, people can't play with it. If someone has to have a serious use before it can be there, it's never going to be easy for anyone to get their feet wet so they might wind up producing something serious.
I hope there settles to be one main, nice, new thing at a higher level with a sane user-level interface, that most everyone wants to use. Manifestly, I have been taking my sweet time coming up with something worth talking about so far. Even when I do produce something like that, I don't expect everyone to like everything about it that I like. Someone else might produce something better or sooner or both--but noone else seems to want to do something else new at the lowest layer. The basic utrace interface is about as straightforward in the core kernel implementation context as it can be while allowing multiple unrelated higher-level agents to coexist, and cleaning up the interfaces into machine-dependent code. The complexities it does have stem from efforts to make it easier not to write bugs in the higher layers and to make it harder to write bugs that badly derail user processes or the system overall. The hope is to give people a chance to write interesting things and mitigate some of the most onerous debugging of such things. Perhaps one day everything anyone wants to do will be based around a higher-level thing by me or someone else, and the need for the low-level utrace platform will fall away. But I tend to think there will always be some specialized uses for which people want a lower-level base to work on. I think of utrace like the block device layer: most people don't care about that layer, they just want to use a filesystem and other things above that; but there are always people who want to do some special thing directly on the lower level, or want to start over building an entirely different style of filesystem.
Thanks,
Roland
Quoted 9 lines · Roland McGrath
Quoted 6 lines
EXPORT_SYMBOL_GPL(utrace_attach);There is not modular user of this, so this and the other
utrace_functions should not be exported. Nor do I think that exporting such a low-level process control is nessecary a good idea, but we'll have to evaluate that if patches to add users show up.If you remove the exports, just throw the whole thing away. The reason utrace exists is to be used by modules.
used != used by modules. Even without things exported you can use things in the kernel. Once we have a valid modular use case we can add exports.
Quoted 8 lines · Christoph Hellwig
Quoted 7 lines · Roland McGrath
Quoted 6 lines
EXPORT_SYMBOL_GPL(utrace_attach);There is not modular user of this, so this and the other
utrace_functions should not be exported. Nor do I think that exporting such a low-level process control is nessecary a good idea, but we'll have to evaluate that if patches to add users show up.
Quoted 6 lines
Quoted 2 lines
If you remove the exports, just throw the whole thing away. The reason utrace exists is to be used by modules.
used != used by modules. Even without things exported you can use things in the kernel. Once we have a valid modular use case we can add exports.
Christoph, it's at
http://people.redhat.com/roland/utrace/crash-suspend.c
The file crash-suspend.c is a simple example of a loadable kernel module using the new infrastructure. It implements the old GNU feature of doing a job suspend on crash, so you can attach a debugger right then instead of just looking at the core file afterwards. Try for example:
$ sudo /sbin/insmod crash-suspend.ko pid=$$ to load the module and attach it to your shell. It then attaches to any children of your shell. Now run something that crashes and would ordinarily dump core--you can just run cat or sleep and hit ^\ to crash it with a SIGQUIT. See it suspend. Try "jobs -l" and see it stopped with a non-stop signal. If you resume it with "fg" it will go ahead and dump core. Or, you can attach a debugger like gdb first, and then debug it.
Most certainly, it should be included into utrace patchset to pin some exports.