[PATCH 00/12] Fix various section mismatches and build errors.

[James Bottomley]

On Wed, 2011-06-29 at 14:07 +0100, Ralf Baechle wrote:
> On Mon, Jun 27, 2011 at 10:12:57PM -0700, David Miller wrote:
> 
> > commit 948252cb9e01d65a89ecadf67be5018351eee15e
> > Author: David S. Miller <davem at davemloft.net>
> > Date:   Tue May 31 19:27:48 2011 -0700
> > 
> >     Revert "net: fix section mismatches"
> >     
> >     This reverts commit e5cb966c0838e4da43a3b0751bdcac7fe719f7b4.
> >     
> >     It causes new build regressions with gcc-4.2 which is
> >     pretty common on non-x86 platforms.
> >     
> >     Reported-by: James Bottomley <James.Bottomley at HansenPartnership.com>
> >     Signed-off-by: David S. Miller <davem at davemloft.net>
> > 
> > and postings that led to this revert including:
> > 
> > http://marc.info/?l=linux-netdev&m=130653748205263&w=2
> 
> Thanks for the pointers; I looked into it a bit deeper and found that the
> construct which hppa64-linux-gcc 4.2.4 doesn't like is the combination of
> const and __devinitconst __devinitdata.
> 
> My patches are minimalistic and don't do any constification and seem to
> work fine for PA-RISC.
> 
> A possible alternative to allow the use of Michał's reverted patch would
> be to conditionalize the definition of __devinitconst.  There is no
> user of __devexitconst so I left that unchanged.

To be honest, my own take on this is that, apart from the compiler
cockups trying to do read only annotations, which affect various
versions of gcc not just the parisc ones, the _devX annotations are
pretty pointless.  They only really do something in the non-hotplug
case, so since 95% of the world seems to use hotplug now and the other
5% doesn't care that much about the odd page of memory (which you rarely
get, since modules sections are accumulated per module, not aggregate),
I'd just favour stripping __init and __exit where there's a problem.

I think we should simply concentrate on __init and __exit; that's where
most of the discard value lies and stop expending huge efforts on the
__devX stuff which adds huge complexity for no real gain.

James