On 03/10/17 09:03, Daniel Vetter wrote:
On Mon, Oct 02, 2017 at 12:00:54PM +0300, Jani Nikula wrote:
On Mon, 02 Oct 2017, Daniel Thompson <daniel.thompson@xxxxxxxxxx> wrote:
So I'm coming to this patchset cold but can you explain *why* something
wants to call of_find_backlight_by_node() when there is no backlight
support enabled. Why isn't the code that called is conditional on
BACKLIGHT_CLASS_DEVICE?
The undefined symbol issue is a pain but to be honest I'd rather solve
the use of undefined symbols by avoiding declaring them; this making
them into compile errors rather than link errors.
Typically the kernel header files define static inline stubs of the
functions when the actual functions aren't configured/built. The code
using the functions looks the same regardless of the config option, and
handles the -ENODEV or NULL or whatever returns from the stubs
gracefully. With the inlines, the compiler can usually throw out much of
the code anyway.
In this regard, the backlight interface is an exception, forcing the
callers to wrap the code around IS_ENABLED(BACKLIGHT_CLASS_DEVICE), not
the rule.
fwiw, I think it'd be great if we can move backlight over to the common
pattern, like everyone else. It's pretty big pain as-is ...
For sure, after Jani's mail yesterday I looked at the GMA500 driver and
concluded I didn't want code related to backlight having to look like that!
Currently the three main patterns of use are:
1. Standalone drivers simple depend on BACKLIGHT_CLASS_DEVICE,
2. Some compound drivers select BACKLIGHT_CLASS_DEVICE (the AMD DRM
driver is an example of this),
3. Other compound drivers perform heroics with the pre-processor.
The main reason I'm not just agreeing straight away is that, to adopt
the static inline pattern for the whole API, we have to believe that #3
above is desirable. Given the size and scope of the compound drivers in
#3 above, I don't entirely understand why they want to avoid the select.
Daniel.
PS Whatever the outcome here, I do agree 100% that is wrong to prototype
undefined symbols. That must be changed!
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
