Hello Guenter,

On 5/11/22 19:17, Guenter Roeck wrote:

On 5/11/22 10:00, Sam Ravnborg wrote:

[snip]

quoted

quoted

  struct fb_info *registered_fb[FB_MAX] __read_mostly;
-EXPORT_SYMBOL(registered_fb);
-
  int num_registered_fb __read_mostly;
+#if IS_ENABLED(CONFIG_FB_OLPC_DCON)
+EXPORT_SYMBOL(registered_fb);
  EXPORT_SYMBOL(num_registered_fb);
+#endif

It is stuff like this I refer to as "ugly" in the comment above.

My "solution" for that kind of thing is to use a namespace,
such as

EXPORT_SYMBOL_NS(registered_fb, FB_OLPC_DCON);
EXPORT_SYMBOL_NS(num_registered_fb, FB_OLPC_DCON);

Using a namespace in this case is indeed a great idea I think.

I've used in the past to limit the export of a symbol for within a driver
that could be scattered across different compilations units, but it never
occurred to me using it to limit symbols exported by core code.
 

and import it from the offending code. That avoids ifdefs
while at the same time limiting the use of the symbols
to the expected scope. Of course that could be abused but
that abuse would be obvious.

Agreed. For the next revision, besides using an namespaced export symbol
as you suggested, I'll include a comment to make clear that it shouldn't
by any other driver and FB_OLPC_DCON fixed instead.


-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat