Re: CONFIG_OPTIMIZE_INLINING

Ingo Molnar
2008-04-27T11:23:25Z

* David Miller <davem@davemloft.net> wrote:

> From: Ingo Molnar <mingo@elte.hu>
> Date: Sun, 27 Apr 2008 07:59:43 +0200
>
> > ... as i saw no reason why this feature, which i found rather
> > useful, should be delayed another year or so. I'd be more than happy
> > to promote this feature back to lib/Kconfig.debug, sparc64 interest
> > would make that a strong argument.
>
> So you caved in to FUD in order to pad your commit and signoff count?
>
> Because anyone who is paying attention can see clearly that you're
> trying to push as much stuff as quickly as possible into Linus's tree
> with your singoffs and authorship on it this merge window.
>
> Gee, I wonder why...

That suggestion is ridiculous but i guess i have to reply to it.

Firstly, i've been given more credit in Linux already than is enough for
a lifetime ;-) 1000+ changes down the line the joy of having yet another
commit upstream is ... minimal. I'm more interested in seeing Linux
progress as a whole and most of my pride goes towards the whole
structure not towards individual changes.

Secondly, you dont even have to take my word on this one. Was there even
a shred of truth to the claim above i'd surely must have split up this
recent x86 commit into many small commits:

| commit a4928cffe6435caf427ae673131a633c1329dbf3
| Author: Ingo Molnar <mingo@elte.hu>
| Date: Wed Apr 23 13:20:56 2008 +0200
|
| "make namespacecheck" fixes
|
| Signed-off-by: Ingo Molnar <mingo@elte.hu>

arch/x86/kernel/apic_32.c | 2 +-
arch/x86/kernel/apic_64.c | 4 ++--
arch/x86/kernel/process_32.c | 2 +-
arch/x86/kernel/process_64.c | 2 +-
arch/x86/kernel/setup_32.c | 4 ++--
arch/x86/kernel/smpboot.c | 12 ++++++------
arch/x86/kernel/tlb_64.c | 2 +-
arch/x86/kernel/vsyscall_64.c | 2 +-
arch/x86/mm/dump_pagetables.c | 2 +-
arch/x86/mm/pageattr.c | 2 +-
arch/x86/mm/srat_64.c | 2 +-
include/asm-x86/smp.h | 1 -
include/asm-x86/tsc.h | 1 -
13 files changed, 18 insertions(+), 20 deletions(-)

i could have made that 13 separate commits - as it is done with these
kinds of commits all around the tree (networking included, see commit
263173af).

Right?

And i routinely backmerge my fixlets into the body of the patch. In the
current merge window alone:

$ earth4:~/v> git-log v2.6.25.. | grep ' \[ mingo@elte'
[ mingo@elte.hu: minor cleanups. ]
[ mingo@elte.hu: redesign, splitups, cleanups. ]
[ mingo@elte.hu: heavily modified, simplified and cleaned up. ]
[ mingo@elte.hu: do it on gbpages kernels too, there's no clear reason
> [ mingo@elte.hu: build fix ]
[ mingo@elte.hu: build fix ]
[ mingo@elte.hu: fix boot regression. ]
[ mingo@elte.hu: x86: fix the pagetable dumper ]

... without creating a separate commit for the fixes.

But it's more than that: in fact i change the code in the _majority of
commits_ that i accept (various minor errors are very common), without
creating small fixlets. Most of the patches have to be edited trivially
for one or another reason - and that's just the code portion - 99% of
the commit messages of them has to be edited, most of them
substantially.

So if i were creating commits for each of those edits we'd have ~500-600
more trivial commits in this merge window alone. And i know you do this
fix backmerging too and it's the correct maintenance practice IMO.

As an example for this practice, look at the current raw, unprocessed,
not-yet-backmerged ftrace tree that i just posted to lkml. It has 34
commits from me:

> > Ingo Molnar (34):

about 30 of those commits will go away completely by the time i post
that for upstream.

So not only is that claim patently untrue, it's the _exact opposite_ of
what i'm doing day to day.

Ingo