Hello Guenter,
On 5/11/22 19:17, Guenter Roeck wrote:
On 5/11/22 10:00, Sam Ravnborg wrote:
[snip]
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.