> Not sure I understand. Do you mean it is possible to move the code from > the old file to the new one in a git-friendly manner? Afaics, there is no > way to do this, git can only hanlde renames. (but my git skills is close > to zero).
What I meant is a sequence of patches like: 1. move non-common code from ptrace.c to ptrace-old.c 2. rename ptrace.c to ptrace.h 3. rename ptrace-old.c to ptrace.c or numerous other sequences that have that property, where one of the steps in the sequence renames a file without changing it. (That example is not a particularly good idea.) > This is what I'd like to avoid as much as possible. As usual, this is very > subjective, but imho this way it will be very difficult to read the code, > even if we have a single ifdef which separates the old and new implementation. > Say, not good to have 2 almost identical ptrace_attach() implementations in > the same file. I agree that's ugly. > Instead of the single ifdef, we can add a lot of them. For example, as for > ptrace_attach() we can do Opinions also vary on whether that is more or less ugly. For some reason there seems to be a preference upstream for repeating identical declarations on both sides of an #ifdef over putting an #ifdef inside a function. I don't really get it. > In this case kernelptrace.c becomes > > ... the context of kernel/ptrace-common.h ... > > #ifndef CONFIG_UTRACE > ... other code ... > #endif > > and we don't need CONFIG_PTRACE_OLD. > > Do you agree with approach? That's what I had in mind. But I'm almost sorry I raised the issue. I don't think there is much benefit to debating these details amongst ourselves. The right answer is whatever the upstream reviewers demand. You and I just want something merged ASAP and all the nits are secondary. Thanks, Roland
