Re: CONFIG_OPTIMIZE_INLINING

[Ingo Molnar]

* David Miller <davem@xxxxxxxxxxxxx> wrote:

> From: Ingo Molnar <mingo@xxxxxxx>
> 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@xxxxxxx>
| Date:   Wed Apr 23 13:20:56 2008 +0200
|
|    "make namespacecheck" fixes
|
|    Signed-off-by: Ingo Molnar <mingo@xxxxxxx>

  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@xxxxxxx: minor cleanups. ]
    [ mingo@xxxxxxx: redesign, splitups, cleanups. ]
    [ mingo@xxxxxxx: heavily modified, simplified and cleaned up. ]
    [ mingo@xxxxxxx: do it on gbpages kernels too, there's no clear reason
    >     [ mingo@xxxxxxx: build fix ]
    [ mingo@xxxxxxx: build fix ]
    [ mingo@xxxxxxx: fix boot regression. ]
    [ mingo@xxxxxxx: 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/