From: Javier Martinez Canillas <javierm@redhat.com>
To: Guenter Roeck <linux@roeck-us.net>, Sam Ravnborg <sam@ravnborg.org>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Helge Deller <deller@gmx.de>,
Thomas Zimmermann <tzimmermann@suse.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
kernel test robot <lkp@intel.com>,
Jens Frederich <jfrederich@gmail.com>,
Jon Nettleton <jon.nettleton@gmail.com>,
linux-staging@lists.linux.dev,
Daniel Vetter <daniel.vetter@intel.com>,
Daniel Vetter <daniel@ffwll.ch>,
Matthew Wilcox <willy@infradead.org>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Zhen Lei <thunder.leizhen@huawei.com>,
Alex Deucher <alexander.deucher@amd.com>,
Xiyu Yang <xiyuyang19@fudan.edu.cn>,
Zheyu Ma <zheyuma97@gmail.com>
Subject: Re: [PATCH v5 7/7] fbdev: Make registered_fb[] private to fbmem.c
Date: Wed, 11 May 2022 19:34:38 +0200 [thread overview]
Message-ID: <48f164af-99d2-9e74-e307-003be0677384@redhat.com> (raw)
In-Reply-To: <8c84428c-2740-4046-74c9-298b854944d0@roeck-us.net>
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.
--
Best regards,
Javier Martinez Canillas
Linux Engineering
Red Hat
next prev parent reply other threads:[~2022-05-11 17:34 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-11 11:24 [PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe Javier Martinez Canillas
2022-05-11 11:24 ` [PATCH v5 1/7] firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer Javier Martinez Canillas
2022-05-11 12:04 ` Javier Martinez Canillas
2022-05-11 11:24 ` [PATCH v5 2/7] firmware: sysfb: Add helpers to unregister a pdev and disable registration Javier Martinez Canillas
2022-05-11 11:54 ` Thomas Zimmermann
2022-05-11 12:01 ` Javier Martinez Canillas
2022-05-11 12:05 ` Thomas Zimmermann
2022-05-11 12:29 ` Javier Martinez Canillas
2022-05-11 12:02 ` Thomas Zimmermann
2022-05-11 12:24 ` Javier Martinez Canillas
2022-05-11 11:30 ` [PATCH v5 3/7] fbdev: Restart conflicting fb removal loop when unregistering devices Javier Martinez Canillas
2022-05-11 11:47 ` Thomas Zimmermann
2022-05-11 11:57 ` Javier Martinez Canillas
2022-05-13 12:28 ` Javier Martinez Canillas
2022-05-11 11:31 ` [PATCH v5 4/7] fbdev: Make sysfb to unregister its own registered devices Javier Martinez Canillas
2022-05-11 11:31 ` [PATCH v5 5/7] fbdev: Disable sysfb device registration when removing conflicting FBs Javier Martinez Canillas
2022-06-07 15:01 ` Daniel Vetter
2022-06-07 15:41 ` Javier Martinez Canillas
2022-05-11 11:32 ` [PATCH v5 6/7] Revert "fbdev: Prevent probing generic drivers if a FB is already registered" Javier Martinez Canillas
2022-05-11 11:32 ` [PATCH v5 7/7] fbdev: Make registered_fb[] private to fbmem.c Javier Martinez Canillas
2022-05-11 17:00 ` Sam Ravnborg
2022-05-11 17:17 ` Guenter Roeck
2022-05-11 17:34 ` Javier Martinez Canillas [this message]
2022-05-12 18:32 ` Sam Ravnborg
2022-05-13 10:48 ` [PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe Thomas Zimmermann
2022-05-13 11:10 ` Javier Martinez Canillas
2022-05-13 11:32 ` Thomas Zimmermann
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=48f164af-99d2-9e74-e307-003be0677384@redhat.com \
--to=javierm@redhat.com \
--cc=alexander.deucher@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=jfrederich@gmail.com \
--cc=jon.nettleton@gmail.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=linux@roeck-us.net \
--cc=lkp@intel.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=sam@ravnborg.org \
--cc=thunder.leizhen@huawei.com \
--cc=tzimmermann@suse.de \
--cc=willy@infradead.org \
--cc=xiyuyang19@fudan.edu.cn \
--cc=zheyuma97@gmail.com \
/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).