From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: David Miller <davem@davemloft.net>
Cc: mirq-linux@rere.qmqm.pl, netdev@vger.kernel.org
Subject: Re: Section conflict compile failures in net
Date: Wed, 01 Jun 2011 10:42:50 +0900 [thread overview]
Message-ID: <1306892570.11897.35.camel@mulgrave.site> (raw)
In-Reply-To: <20110531.154531.493226762.davem@davemloft.net>
On Tue, 2011-05-31 at 15:45 -0700, David Miller wrote:
> From: James Bottomley <James.Bottomley@HansenPartnership.com>
> Date: Thu, 26 May 2011 16:39:53 -0500
>
> BTW, linux-netdev doesn't exist, it's just plain netdev.
Um, yes ... I thought it was netdev, then I checked MARC and it had
linux-netdev. I'll remember for next time (well, at least for the next
six months).
> > Simply reverting
> >
> > commit e5cb966c0838e4da43a3b0751bdcac7fe719f7b4
> > Author: Micha<C5><82> Miros<C5><82>aw <mirq-linux@rere.qmqm.pl>
> > Date: Mon Apr 18 13:31:20 2011 +0000
> >
> > net: fix section mismatches
> >
> > Fixes the problem.
> >
> > If I look at the first problem in hp100.c, the addition of
> > __devinitconst to the device tables is fine, but there's no
> > corresponding sectional tag on their use, so when compiled as a module,
> > things like hp100_eisa_driver is now in the main data section but refers
> > to something in the init data section ... I assume all the others are
> > the same type of problem.
>
> Yeah I think the device ID table __devinitconst bits have to be
> reverted.
>
> I'll apply something like the following:
>
> net: Revert adding __devinitconst to driver ID tables.
>
> If the table is hooked up to foo_driver->id_table we can't
> mark it __devinitconst otherwise we end up with section
> mismatches.
>
> Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
That fixes some but not all; the pci tables still cause a section
conflict:
drivers/net/hp100.c:211: error: hp100_pci_tbl causes a section type conflict
make[2]: *** [drivers/net/hp100.o] Error 1
It's really, as has been said, a compiler problem: the compiler is
confused about the read only sections. However, 4.2 is a pretty common
compiler (especially for non-x86), so if the compiler can't do the read
only section tracking, just not using the __devinitconst designation
globally seems to be the best thing, just change it to __devinitdata
instead.
James
next prev parent reply other threads:[~2011-06-01 1:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1306445993.4048.58.camel@mulgrave.site>
[not found] ` <20110527080728.GA2108@rere.qmqm.pl>
2011-05-27 23:04 ` Section conflict compile failures in net James Bottomley
2011-05-28 9:05 ` Michał Mirosław
2011-05-31 22:45 ` David Miller
2011-06-01 1:27 ` Michał Mirosław
2011-06-01 2:24 ` David Miller
2011-06-01 1:42 ` James Bottomley [this message]
2011-06-01 2:25 ` David Miller
2011-06-18 17:06 ` Michał Mirosław
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=1306892570.11897.35.camel@mulgrave.site \
--to=james.bottomley@hansenpartnership.com \
--cc=davem@davemloft.net \
--cc=mirq-linux@rere.qmqm.pl \
--cc=netdev@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).