* Ananth N Mavinakayanahalli <ana...@in.ibm.com> wrote:
> > nice! The simplification factor is already significant:
> >
> > 18 files changed, 116 insertions(+), 175 deletions(-)
> >
> > That is what we want - to remove special TIF flag uses and replace
> > them with utrace driven machinery.
> >
> > Another future target could be to replace TIF_SYSCALL_FTRACE [in the
> > latest tracing tree] with a similar utrace driven solution.
> >
> > 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
> >
> > 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?
>
> Thats because the version of ptrace.c you are looking at has both the
> legacy implementation and the ptrace over utrace implementation with
> #ifdefs to separate them out. I guess Roland wanted to keep the
> #legacy stuff around till the ptrace/utrace becomes stable enough.
But this makes it hard to judge how upstream-worthy that change is -
or could be. I realize that it's incomplete, so i'm guessing.
kernel/ptrace.c is 739 lines currently, arch/x86/kernel/ptrace.c is
1467 lines. The +794 lines via ptrace/utrace suggest that it got a
bit larger - or at least has roughly the same size.
Can arch/x86/kernel/trace.c be eliminated altogether? If yes then
that would make it a clear net win, with just a single architecture
covered. With every additional arch the win (==complexity reduction)
would be larger.
Ingo
