[SCM] strace branch, master, updated. v4.6-109-ga614692

[Denys Vlasenko]

On Thu, 2011-08-25 at 13:22 +0400, Dmitry V. Levin wrote:
> On Wed, Aug 24, 2011 at 04:13:48PM +0000, Denys Vlasenko wrote:
> > commit a614692fb082294ae3d3c7f6c1ed26b355d6c4bf
> > Author: Denys Vlasenko <dvlasenk at redhat.com>
> > Date:   Wed Aug 24 18:07:22 2011 +0200
> > 
> >     Reorder functions in syscall.c. No code changes.
> >     
> >     Old order (basically "in no particular order"):
> >         dumpio
> >         decode_subcall
> >         internal_syscall
> >         get_scno
> >         get_syscall_result
> >         known_scno
> >         syscall_fixup
> >         is_negated_errno
> >         get_error
> >         syscall_enter
> >         trace_syscall_entering
> >         trace_syscall_exiting
> >         trace_syscall
> >         printargs
> >         getrval2
> >         sys_indir
> >         is_restart_error
> >     
> >     New order:
> >     various utility functions:
> >         decode_subcall
> >         printargs
> >         getrval2
> >         sys_indir
> >         is_restart_error
> >     syscall enter handling functions:
> >         get_scno
> >         known_scno
> >         syscall_fixup (also used in syscall exit code)
> >         internal_syscall (also used in syscall exit code)
> >         syscall_enter
> >         trace_syscall_entering
> >     syscall exit handling functions:
> >         get_syscall_result
> >         is_negated_errno
> >         get_error
> >         dumpio
> >         trace_syscall_exiting
> >     main syscall enter/exit function:
> >         trace_syscall
> >     
> >     * syscall.c: Reorder functions so that related ones are closer
> >     in the source.
> 
> Ouch.  I avoid such changes if at all possible because they ruin history
> tracking completely.

I agree. But over time, syscall.c become a jungle of badly-named
and randomly placed functions. It took a dozen patches to make it
possible to even _see_ the possibility of optimizations I committed
recently.

>   Even code re-indentation is less evil, thanks to
> various methods of ignoring whitespace changes.  I have no idea how to
> review this change, git diff is utterly useless here.  Lets hope there
> are no accidental mistakes...

I know.

In case I move a function, I never change its body while moving it.
If I want to do that, I do it in a separate commit.

-- 
vda