lkml.org 
[lkml]   [2008]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Are Section mismatches out of control?
From
Date
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




\
 
 \ /
  Last update: 2008-02-01 16:03    [W:0.132 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site