All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Adrian Bunk <bunk@kernel.org>,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: 2.6.25 and DEBUG_SECTION_MISMATCH
Date: Wed, 16 Apr 2008 23:08:38 +0200	[thread overview]
Message-ID: <20080416210838.GA27459@elte.hu> (raw)
In-Reply-To: <20080416205230.GA4129@uranus.ravnborg.org>


* Sam Ravnborg <sam@ravnborg.org> wrote:

> On Wed, Apr 16, 2008 at 09:55:04PM +0200, Ingo Molnar wrote:
> > 
> > * Ingo Molnar <mingo@elte.hu> wrote:
> > 
> > > * Sam Ravnborg <sam@ravnborg.org> wrote:
> > > 
> > > > I would prefer we were down to less than 5 warnings so we could 
> > > > enable it in kconfig but maybe after next merge window.
> > > 
> > > they get regenerated. More than 1 out of every 100 new patches. Quite 
> > > expensive feature (in terms of maintenance overhead) for a rather 
> > > theoretical memory saving benefit.
> > 
> > in v2.6.24 we had at least 200 section fixes:
> > 
> >   $ git-log v2.6.24.. | egrep -c 'WARNING:.*Section mismatch'
> >   198
> > 
> > for 12671 commits - that's 1 section type fix for every 60 commits.
> Please get your numbers right. What you count is the number of Section 
> mismatch warnings that has been fixed. Sometime fixing up one line of 
> code fixes >5 section mismatch warnings.

the revised number is: at least 84 commits that fixed section bugs. 
That's still rather large.

> > and 90% of the problems could be reduced via the very simple patch 
> > below ...
> > 
> > so ... why shouldnt we say that if someone wants to have this 
> > feature, it should be done all automatically, in the link space. 
> > There's no reason why the dependencies couldnt be figured out all 
> > automatically.
> 
> Or we could fix the blatant misuse of __cpuinit. If has replaced a 
> proper separation of code that is only relevant for CPU hotplug and 
> code that is used with and without CPUHOTPLUG.
> 
> I question that we have 580 functions that is used duing init in 
> normal cases and during CPU hotplug.

sure, if you can solve it, please do - but the stream of new section 
warnings and seems somewhat worrying for the long run.

	Ingo

      reply	other threads:[~2008-04-16 21:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-16 17:51 2.6.25 and DEBUG_SECTION_MISMATCH Adrian Bunk
2008-04-16 19:22 ` Jacek Luczak
2008-04-16 19:23 ` Sam Ravnborg
2008-04-16 19:31   ` Ingo Molnar
2008-04-16 19:49     ` Jacek Luczak
2008-04-16 19:55     ` Ingo Molnar
2008-04-16 20:52       ` Sam Ravnborg
2008-04-16 21:08         ` Ingo Molnar [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080416210838.GA27459@elte.hu \
    --to=mingo@elte.hu \
    --cc=bunk@kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.