linux-kernel - Re: CONFIG_OPTIMIZE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080427112256.GA23139@elte.hu>
Date:	Sun, 27 Apr 2008 13:22:56 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	David Miller <davem@...emloft.net>
Cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, viro@...IV.linux.org.uk
Subject: Re: CONFIG_OPTIMIZE_INLINING

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

> From: Ingo Molnar <mingo@...e.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@...e.hu>
| Date:   Wed Apr 23 13:20:56 2008 +0200
|
|    "make namespacecheck" fixes
|
|    Signed-off-by: Ingo Molnar <mingo@...e.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@...e'
    [ mingo@...e.hu: minor cleanups. ]
    [ mingo@...e.hu: redesign, splitups, cleanups. ]
    [ mingo@...e.hu: heavily modified, simplified and cleaned up. ]
    [ mingo@...e.hu: do it on gbpages kernels too, there's no clear reason
    >     [ mingo@...e.hu: build fix ]
    [ mingo@...e.hu: build fix ]
    [ mingo@...e.hu: fix boot regression. ]
    [ mingo@...e.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/