Re: kbuild: Section mismatch warnings

[Greg KH <gregkh@suse.de>]

On Sun, Feb 19, 2006 at 01:21:33AM +0100, Sam Ravnborg wrote:
> On Fri, Feb 17, 2006 at 04:09:21PM -0800, Greg KH wrote:
> > On Fri, Feb 17, 2006 at 11:47:02PM +0100, Sam Ravnborg wrote:
> > > Background:
> > > I have introduced a build-time check for section mismatch and it showed
> > > up a great number of warnings.
> > > Below is the result of the run on a 2.6.16-rc1 tree (which my kbuild
> > > tree is based upon) based on a 'make allmodconfig'
> 
> Greg - related to this I have thought a bit on __devinit versus __init.
> With HOTPLUG enabled __devinit becomes empty and thus violate any checks
> for illegal references to .init.text.

I _really_ hate __devinit.  Almost everyone who uses it gets it wrong
the first time (like pci hotplug drivers using it, which is just
pointless...)  Now that CONFIG_HOTPLUG is always enabled (well, it's a
lot harder to disable it now), hopefully when people get it wrong it
will not cause problems.

> Would it make sense to create a specific set of sections for __devinit
> and frinds so we could check that __devinit sections are not referenced from .text.
> This is another way to do the current __init checks but with HOTPLUG
> enabled and I like the result to be consistent with and without HOTPLUG
> enabled.

That's not a bad idea.

> Also I see __devinit being used in different ways. See sound/oss/mad16
> for instance.
> Only a few functions are marked __devinit nad I wonder if any should be
> marked __devinit at all in that file. But due to references to
> __initdata current checks discovered a potential bug here already today.

Like I said above, almost everyone uses it incorrectly.  I went through
the whole tree sometime late 2.5 and fixed up everything.  It's probably
time for another audit...

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/