From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Sam Ravnborg <sam@ravnborg.org>,
LKML <linux-kernel@vger.kernel.org>,
linux arch <linux-arch@vger.kernel.org>
Subject: Re: Are Section mismatches out of control?
Date: Fri, 01 Feb 2008 09:00:59 -0600 [thread overview]
Message-ID: <1201878059.3134.13.camel@localhost.localdomain> (raw)
In-Reply-To: <20080201030329.9b760777.akpm@linux-foundation.org>
On Fri, 2008-02-01 at 03:03 -0800, Andrew Morton wrote:
> On Fri, 1 Feb 2008 11:47:18 +0100 Sam Ravnborg <sam@ravnborg.org> wrote:
>
> > James said in a related posting that the Section mismatch
> > warnings were getting out of control.
>
> eh. They're easy - the build system tells you about them!
>
> > The list is here:
>
> Question is: why do people keep adding new ones when they are so easy to
> detect and fix?
>
> Asnwer: because neither they nor their patch integrators are doing adequate
> compilation testing.
That's because certain configurations, where this shows up, like !
CONFIG_HOTPLUG or !CONFIG_HOTPLUG_CPU simply aren't anything other than
extremely weird configs for most modern HW and distributions.
I'm not saying we can't fix the problem with tools or that we can't
invest huge amounts of time patching and fixing this. I am saying we
should be questioning the value of the investment in doing so.
I also claim that getting rid of the __dev.* sectional attributes (for
which I've already submitted a small patch) fixes 90% of the problems
(since they're mainly caused by driver writers not understanding what
all of these things mean). The remaining ones are clearer and
additionally, show up on every build (whether HOTPLUG or not).
Before we start to pillory driver writers for not caring about configs
they rightly don't give a toss about, could we at least get someone
(anyone!) in the community that cares about extreme low memory
configurations to give us reasons why there's value to all this effort
(rather than spending it on say reducing cache footprints or eliminating
space in structures)? All the people I've asked so far (mainly in arm,
admittedly) have said they have bigger things to worry about.
James
next prev parent reply other threads:[~2008-02-01 15:01 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-01 10:47 Are Section mismatches out of control? Sam Ravnborg
2008-02-01 11:03 ` Andrew Morton
2008-02-01 11:21 ` Harvey Harrison
2008-02-01 13:30 ` Geert Uytterhoeven
2008-02-01 13:40 ` Sam Ravnborg
2008-02-01 21:22 ` Geert Uytterhoeven
2008-02-01 22:32 ` Sam Ravnborg
2008-02-02 16:42 ` Geert Uytterhoeven
2008-02-02 17:40 ` Sam Ravnborg
2008-02-01 17:02 ` Roland Dreier
2008-02-01 21:47 ` Jan Engelhardt
2008-02-01 22:10 ` James Bottomley
2008-02-01 22:40 ` Sam Ravnborg
2008-02-02 0:01 ` Jan Engelhardt
2008-02-01 14:48 ` Johannes Weiner
2008-02-01 15:00 ` James Bottomley [this message]
2008-02-01 16:43 ` Jeff Garzik
2008-02-01 20:17 ` Sam Ravnborg
2008-02-01 20:24 ` Jeff Garzik
2008-02-01 22:38 ` Sam Ravnborg
2008-02-01 11:10 ` Andi Kleen
2008-02-01 21:51 ` Jan Engelhardt
2008-02-02 4:12 ` Andi Kleen
2008-02-01 14:53 ` James Bottomley
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=1201878059.3134.13.camel@localhost.localdomain \
--to=james.bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=linux-arch@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox