The definition of EXPORT_SYMBOL et al depends on
DEFAULT_SYMBOL_NAMESPACE. So DEFAULT_SYMBOL_NAMESPACE must already be
available when <linux/export.h> is parsed.

Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/linux-i2c/Z09bp9uMzwXRLXuF@smile.fi.intel.com/
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
---
 Documentation/core-api/symbol-namespaces.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/core-api/symbol-namespaces.rst b/Documentation/core-api/symbol-namespaces.rst
index a08a3448cbad..d63e4245a9f5 100644
--- a/Documentation/core-api/symbol-namespaces.rst
+++ b/Documentation/core-api/symbol-namespaces.rst
@@ -80,8 +80,8 @@ unit as preprocessor statement. The above example would then read::
 	#undef  DEFAULT_SYMBOL_NAMESPACE
 	#define DEFAULT_SYMBOL_NAMESPACE "USB_COMMON"
 
-within the corresponding compilation unit before any EXPORT_SYMBOL macro is
-used.
+within the corresponding compilation unit before the #include for
+<linux/export.h>.
 
 3. How to use Symbols exported in Namespaces
 ============================================
-- 
2.45.2

On Wed, Dec 04, 2024 at 11:01:11AM +0100, Uwe Kleine-König wrote:
> The definition of EXPORT_SYMBOL et al depends on
> DEFAULT_SYMBOL_NAMESPACE. So DEFAULT_SYMBOL_NAMESPACE must already be
> available when <linux/export.h> is parsed.

> -within the corresponding compilation unit before any EXPORT_SYMBOL macro is
> -used.
> +within the corresponding compilation unit before the #include for
> +<linux/export.h>.

And how do I know where it is included in the current state of affairs with the
dependency hell in the kernel?

I suggest to reword it to something like "before any global inclusions", the
best probably is to repeat the piece from pr_fmt() / dev_fmt() documentation
(if any).

-- 
With Best Regards,
Andy Shevchenko

Hello Andy,

On Thu, Dec 05, 2024 at 09:52:13AM +0200, Andy Shevchenko wrote:
> On Wed, Dec 04, 2024 at 11:01:11AM +0100, Uwe Kleine-König wrote:
> > The definition of EXPORT_SYMBOL et al depends on
> > DEFAULT_SYMBOL_NAMESPACE. So DEFAULT_SYMBOL_NAMESPACE must already be
> > available when <linux/export.h> is parsed.
> 
> > -within the corresponding compilation unit before any EXPORT_SYMBOL macro is
> > -used.
> > +within the corresponding compilation unit before the #include for
> > +<linux/export.h>.
> 
> And how do I know where it is included in the current state of affairs with the
> dependency hell in the kernel?
> 
> I suggest to reword it to something like "before any global inclusions", the
> best probably is to repeat the piece from pr_fmt() / dev_fmt() documentation
> (if any).

Well, "before <linux/export.h>" is the accurate thing you have to
ensure. "before any global inclusion" is the safe and easy thing to do
to achieve that. Maybe:

	...
	within the corresponding compilation unit before the #include for
	<linux/export.h>. Typically it's placed before the first
	#include.

?

Best regards
Uwe

On Thu, Dec 05, 2024 at 12:21:26PM +0100, Uwe Kleine-König wrote:
> Hello Andy,
> 
> On Thu, Dec 05, 2024 at 09:52:13AM +0200, Andy Shevchenko wrote:
> > On Wed, Dec 04, 2024 at 11:01:11AM +0100, Uwe Kleine-König wrote:
> > > The definition of EXPORT_SYMBOL et al depends on
> > > DEFAULT_SYMBOL_NAMESPACE. So DEFAULT_SYMBOL_NAMESPACE must already be
> > > available when <linux/export.h> is parsed.
> > 
> > > -within the corresponding compilation unit before any EXPORT_SYMBOL macro is
> > > -used.
> > > +within the corresponding compilation unit before the #include for
> > > +<linux/export.h>.
> > 
> > And how do I know where it is included in the current state of affairs with the
> > dependency hell in the kernel?
> > 
> > I suggest to reword it to something like "before any global inclusions", the
> > best probably is to repeat the piece from pr_fmt() / dev_fmt() documentation
> > (if any).
> 
> Well, "before <linux/export.h>" is the accurate thing you have to
> ensure. "before any global inclusion" is the safe and easy thing to do
> to achieve that. Maybe:
> 
> 	...
> 	within the corresponding compilation unit before the #include for
> 	<linux/export.h>. Typically it's placed before the first
> 	#include.

The below is excerpt for pr_fmt():

---8>----
Besides being more concise than the equivalent printk() calls, they can use a
common definition for the format string through the pr_fmt() macro. For
instance, defining this at the top of a source file (before any ``#include``
directive)::

  #define pr_fmt(fmt) "%s:%s: " fmt, KBUILD_MODNAME, __func__

---8>----

> ?


-- 
With Best Regards,
Andy Shevchenko