> Regarding ptrace-via-utrace. What is the plan there? Am i looking > the right branch: > > | earth4:~/linux.trees.git> git diff --stat > | linus/master..utrace/utrace-ptrace kernel/ptrace.c arch/x86/kernel/ptrace.c > | kernel/ptrace.c | 803 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++- > | 1 files changed, 794 insertions(+), 9 deletions(-) > > dc43527: Merge branch 'utrace' into utrace-ptrace
That is the branch that there is, yes. Its comparison vs its baseline is: include/linux/ptrace.h | 21 ++ include/linux/sched.h | 1 + include/linux/tracehook.h | 19 +- init/Kconfig | 18 + kernel/ptrace.c | 785 ++++++++++++++++++++++++++++++++++++++++++++- kernel/signal.c | 14 +- kernel/utrace.c | 23 ++ 7 files changed, 870 insertions(+), 11 deletions(-) > I'd have (perhaps foolishly) expected ptrace.c to get reduced in > size and arch/x86/kernel/ptrace.c eliminated - but that does not > seem to be direction of movement. What am i missing? Expecting that arch file to go away is just a complete misunderstanding on your part. Look at what is actually in that file. arch_ptrace() and compat_arch_ptrace() are the only things there that are actually part of ptrace per se. I'm not sure how much smaller you expect those to get. Firstly, this branch now is hack-and-slash code. As I've said a few times, the bulk of the work is ptrace clean-up that is not directly related to utrace. (It's necessary stuff to do the utrace version sanely, but it's independent clean-up that will go in ahead of any ptrace changes involving utrace.) That will make it cleaner, but probably not smaller in line counts. You get some more lines when you start using sane data structures instead of all kludges. Moreover, that branch does not remove any code at all. Everything is left the same with CONFIG_UTRACE turned off. All the utrace-based ptrace code is new code on the other side of an #else from some old code. None of this, of course, has anything whatsoever to do with the seccomp thread. I don't know why so many people insist on hijacking every thread for every other thing instead of posting a proper thread on a new subject they raise. I suppose it goes along with verbosely reviewing the diffstats while never looking at the actual code, which also seems to be popular. Thanks, Roland
