[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1002171819020.4141@localhost.localdomain>
Date: Wed, 17 Feb 2010 18:22:29 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Grant Likely <grant.likely@...retlab.ca>
cc: Matthew Wilcox <matthew@....cx>,
Andrew Morton <akpm@...ux-foundation.org>,
Adrian Bunk <bunk@...nel.org>,
Andrea Righi <righi.andrea@...il.com>,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: __weak vs ifdef
On Wed, 17 Feb 2010, Grant Likely wrote:
>
> Question. If I use this pattern, and use the __weak attribute on core
> code functions wrapped with a #ifndef, then how does it mesh with
> EXPORT_SYMBOL*() statements?
You can't. Or at least not the traditional way, which is to put the
EXPORT_SYMBOL next to the definition of what gets exported.
If you use __weak, you need to make sure that all users of said weak
symbol are in another file. There are some compiler and/or binutils bugs
with using weak symbols in the same translation unit, so the rule is that
a weak definition hes to be somewhere else from the use - including
EXPORT_SYMBOL.
> I also assume that at the core code site, the EXPORT_SYMBOL() must
> appear inside the #ifndef block so that a #define override doesn't
> break things. Correct?
See above. You can't put it inside the _same_ #ifndef block. You'd have to
put it in a different file, but yes, inside an ifndef. At which point the
linker will just pick the right definition.
However, in general, this probably gets ugly enough that the whole __weak
thing is not great for exported stuff. It's likely mostly useful for some
"generic" arch functionality that is always compiled in.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists