| Message ID | 20241113-hwmon-thermal-v1-1-71270be7f7a2@weissschuh.net (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | hwmon: (core) Avoid ifdef in C source file | expand |
On 11/12/24 20:39, Thomas Weißschuh wrote: > Using an #ifdef in a C source files to have different definitions > of the same symbol makes the code harder to read and understand. > Furthermore it makes it harder to test compilation of the different > branches. > > Replace the ifdeffery with IS_ENABLED() which is just a normal > conditional. > The resulting binary is still the same as before as the compiler > optimizes away all the unused code and definitions. > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > --- > This confused me a bit while looking at the implementation of > HWMON_C_REGISTER_TZ. > --- > drivers/hwmon/hwmon.c | 21 ++++++--------------- > 1 file changed, 6 insertions(+), 15 deletions(-) > > diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c > index 9c35c4d0369d7aad7ea61ccd25f4f63fc98b9e02..86fb674c85d3f54d475be014c3fd3dd74c815c57 100644 > --- a/drivers/hwmon/hwmon.c > +++ b/drivers/hwmon/hwmon.c > @@ -147,11 +147,6 @@ static DEFINE_IDA(hwmon_ida); > > /* Thermal zone handling */ > > -/* > - * The complex conditional is necessary to avoid a cyclic dependency > - * between hwmon and thermal_sys modules. > - */ > -#ifdef CONFIG_THERMAL_OF > static int hwmon_thermal_get_temp(struct thermal_zone_device *tz, int *temp) > { > struct hwmon_thermal_data *tdata = thermal_zone_device_priv(tz); > @@ -257,6 +252,9 @@ static int hwmon_thermal_register_sensors(struct device *dev) > void *drvdata = dev_get_drvdata(dev); > int i; > > + if (!IS_ENABLED(CONFIG_THERMAL_OF)) > + return 0; > + > for (i = 1; info[i]; i++) { > int j; > > @@ -285,6 +283,9 @@ static void hwmon_thermal_notify(struct device *dev, int index) > struct hwmon_device *hwdev = to_hwmon_device(dev); > struct hwmon_thermal_data *tzdata; > > + if (!IS_ENABLED(CONFIG_THERMAL_OF)) > + return; > + > list_for_each_entry(tzdata, &hwdev->tzdata, node) { > if (tzdata->index == index) { > thermal_zone_device_update(tzdata->tzd, There is no dummy function for thermal_zone_device_update(). I really don't want to trust the compiler/linker to remove that code unless someone points me to a document explaining that it is guaranteed to not cause any problems. Guenter > @@ -293,16 +294,6 @@ static void hwmon_thermal_notify(struct device *dev, int index) > } > } > > -#else > -static int hwmon_thermal_register_sensors(struct device *dev) > -{ > - return 0; > -} > - > -static void hwmon_thermal_notify(struct device *dev, int index) { } > - > -#endif /* IS_REACHABLE(CONFIG_THERMAL) && ... */ > - > static int hwmon_attr_base(enum hwmon_sensor_types type) > { > if (type == hwmon_in || type == hwmon_intrusion) > > --- > base-commit: 3022e9d00ebec31ed435ae0844e3f235dba998a9 > change-id: 20241113-hwmon-thermal-2d2da581c276 > > Best regards,
Hi Guenter, On 2024-11-12 22:52:36-0800, Guenter Roeck wrote: > On 11/12/24 20:39, Thomas Weißschuh wrote: > > Using an #ifdef in a C source files to have different definitions > > of the same symbol makes the code harder to read and understand. > > Furthermore it makes it harder to test compilation of the different > > branches. > > > > Replace the ifdeffery with IS_ENABLED() which is just a normal > > conditional. > > The resulting binary is still the same as before as the compiler > > optimizes away all the unused code and definitions. > > > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > > --- > > This confused me a bit while looking at the implementation of > > HWMON_C_REGISTER_TZ. > > --- > > drivers/hwmon/hwmon.c | 21 ++++++--------------- > > 1 file changed, 6 insertions(+), 15 deletions(-) > > > > diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c > > index 9c35c4d0369d7aad7ea61ccd25f4f63fc98b9e02..86fb674c85d3f54d475be014c3fd3dd74c815c57 100644 > > --- a/drivers/hwmon/hwmon.c > > +++ b/drivers/hwmon/hwmon.c > > @@ -147,11 +147,6 @@ static DEFINE_IDA(hwmon_ida); > > /* Thermal zone handling */ > > -/* > > - * The complex conditional is necessary to avoid a cyclic dependency > > - * between hwmon and thermal_sys modules. > > - */ > > -#ifdef CONFIG_THERMAL_OF > > static int hwmon_thermal_get_temp(struct thermal_zone_device *tz, int *temp) > > { > > struct hwmon_thermal_data *tdata = thermal_zone_device_priv(tz); > > @@ -257,6 +252,9 @@ static int hwmon_thermal_register_sensors(struct device *dev) > > void *drvdata = dev_get_drvdata(dev); > > int i; > > + if (!IS_ENABLED(CONFIG_THERMAL_OF)) > > + return 0; > > + > > for (i = 1; info[i]; i++) { > > int j; > > @@ -285,6 +283,9 @@ static void hwmon_thermal_notify(struct device *dev, int index) > > struct hwmon_device *hwdev = to_hwmon_device(dev); > > struct hwmon_thermal_data *tzdata; > > + if (!IS_ENABLED(CONFIG_THERMAL_OF)) > > + return; > > + > > list_for_each_entry(tzdata, &hwdev->tzdata, node) { > > if (tzdata->index == index) { > > thermal_zone_device_update(tzdata->tzd, > > There is no dummy function for thermal_zone_device_update(). > I really don't want to trust the compiler/linker to remove that code > unless someone points me to a document explaining that it is guaranteed > to not cause any problems. I'm fairly sure that a declaration should be enough, and believe to remember seeing such advise somewhere. However there is not even a function declaration with !CONFIG_THERMAL. So I can add an actual stub for it for v2. What do you think? Thomas > > @@ -293,16 +294,6 @@ static void hwmon_thermal_notify(struct device *dev, int index) > > } > > } > > -#else > > -static int hwmon_thermal_register_sensors(struct device *dev) > > -{ > > - return 0; > > -} > > - > > -static void hwmon_thermal_notify(struct device *dev, int index) { } > > - > > -#endif /* IS_REACHABLE(CONFIG_THERMAL) && ... */ > > - > > static int hwmon_attr_base(enum hwmon_sensor_types type) > > { > > if (type == hwmon_in || type == hwmon_intrusion) > > > > --- > > base-commit: 3022e9d00ebec31ed435ae0844e3f235dba998a9 > > change-id: 20241113-hwmon-thermal-2d2da581c276 > > > > Best regards, >
On 11/13/24 20:40, Thomas Weißschuh wrote: > Hi Guenter, > > On 2024-11-12 22:52:36-0800, Guenter Roeck wrote: >> On 11/12/24 20:39, Thomas Weißschuh wrote: >>> Using an #ifdef in a C source files to have different definitions >>> of the same symbol makes the code harder to read and understand. >>> Furthermore it makes it harder to test compilation of the different >>> branches. >>> >>> Replace the ifdeffery with IS_ENABLED() which is just a normal >>> conditional. >>> The resulting binary is still the same as before as the compiler >>> optimizes away all the unused code and definitions. >>> >>> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> >>> --- >>> This confused me a bit while looking at the implementation of >>> HWMON_C_REGISTER_TZ. >>> --- >>> drivers/hwmon/hwmon.c | 21 ++++++--------------- >>> 1 file changed, 6 insertions(+), 15 deletions(-) >>> >>> diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c >>> index 9c35c4d0369d7aad7ea61ccd25f4f63fc98b9e02..86fb674c85d3f54d475be014c3fd3dd74c815c57 100644 >>> --- a/drivers/hwmon/hwmon.c >>> +++ b/drivers/hwmon/hwmon.c >>> @@ -147,11 +147,6 @@ static DEFINE_IDA(hwmon_ida); >>> /* Thermal zone handling */ >>> -/* >>> - * The complex conditional is necessary to avoid a cyclic dependency >>> - * between hwmon and thermal_sys modules. >>> - */ >>> -#ifdef CONFIG_THERMAL_OF >>> static int hwmon_thermal_get_temp(struct thermal_zone_device *tz, int *temp) >>> { >>> struct hwmon_thermal_data *tdata = thermal_zone_device_priv(tz); >>> @@ -257,6 +252,9 @@ static int hwmon_thermal_register_sensors(struct device *dev) >>> void *drvdata = dev_get_drvdata(dev); >>> int i; >>> + if (!IS_ENABLED(CONFIG_THERMAL_OF)) >>> + return 0; >>> + >>> for (i = 1; info[i]; i++) { >>> int j; >>> @@ -285,6 +283,9 @@ static void hwmon_thermal_notify(struct device *dev, int index) >>> struct hwmon_device *hwdev = to_hwmon_device(dev); >>> struct hwmon_thermal_data *tzdata; >>> + if (!IS_ENABLED(CONFIG_THERMAL_OF)) >>> + return; >>> + >>> list_for_each_entry(tzdata, &hwdev->tzdata, node) { >>> if (tzdata->index == index) { >>> thermal_zone_device_update(tzdata->tzd, >> >> There is no dummy function for thermal_zone_device_update(). >> I really don't want to trust the compiler/linker to remove that code >> unless someone points me to a document explaining that it is guaranteed >> to not cause any problems. > > I'm fairly sure that a declaration should be enough, and believe > to remember seeing such advise somewhere. > However there is not even a function declaration with !CONFIG_THERMAL. > So I can add an actual stub for it for v2. > > What do you think? > You mean an extern declaration without the actual function ? I'd really want to see that documented. It would seem rather unusual. Besides, there are several other #ifdefs in the same file, so I am not as much bothered about this as you are. Thanks, Guenter
On 2024-11-13 22:51:37-0800, Guenter Roeck wrote: > On 11/13/24 20:40, Thomas Weißschuh wrote: > > On 2024-11-12 22:52:36-0800, Guenter Roeck wrote: > > > On 11/12/24 20:39, Thomas Weißschuh wrote: > > > > Using an #ifdef in a C source files to have different definitions > > > > of the same symbol makes the code harder to read and understand. > > > > Furthermore it makes it harder to test compilation of the different > > > > branches. > > > > > > > > Replace the ifdeffery with IS_ENABLED() which is just a normal > > > > conditional. > > > > The resulting binary is still the same as before as the compiler > > > > optimizes away all the unused code and definitions. > > > > > > > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > > > > --- > > > > This confused me a bit while looking at the implementation of > > > > HWMON_C_REGISTER_TZ. > > > > --- > > > > drivers/hwmon/hwmon.c | 21 ++++++--------------- > > > > 1 file changed, 6 insertions(+), 15 deletions(-) > > > > > > > > diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c > > > > index 9c35c4d0369d7aad7ea61ccd25f4f63fc98b9e02..86fb674c85d3f54d475be014c3fd3dd74c815c57 100644 > > > > --- a/drivers/hwmon/hwmon.c > > > > +++ b/drivers/hwmon/hwmon.c > > > > @@ -147,11 +147,6 @@ static DEFINE_IDA(hwmon_ida); > > > > /* Thermal zone handling */ > > > > -/* > > > > - * The complex conditional is necessary to avoid a cyclic dependency > > > > - * between hwmon and thermal_sys modules. > > > > - */ > > > > -#ifdef CONFIG_THERMAL_OF > > > > static int hwmon_thermal_get_temp(struct thermal_zone_device *tz, int *temp) > > > > { > > > > struct hwmon_thermal_data *tdata = thermal_zone_device_priv(tz); > > > > @@ -257,6 +252,9 @@ static int hwmon_thermal_register_sensors(struct device *dev) > > > > void *drvdata = dev_get_drvdata(dev); > > > > int i; > > > > + if (!IS_ENABLED(CONFIG_THERMAL_OF)) > > > > + return 0; > > > > + > > > > for (i = 1; info[i]; i++) { > > > > int j; > > > > @@ -285,6 +283,9 @@ static void hwmon_thermal_notify(struct device *dev, int index) > > > > struct hwmon_device *hwdev = to_hwmon_device(dev); > > > > struct hwmon_thermal_data *tzdata; > > > > + if (!IS_ENABLED(CONFIG_THERMAL_OF)) > > > > + return; > > > > + > > > > list_for_each_entry(tzdata, &hwdev->tzdata, node) { > > > > if (tzdata->index == index) { > > > > thermal_zone_device_update(tzdata->tzd, > > > > > > There is no dummy function for thermal_zone_device_update(). > > > I really don't want to trust the compiler/linker to remove that code > > > unless someone points me to a document explaining that it is guaranteed > > > to not cause any problems. > > > > I'm fairly sure that a declaration should be enough, and believe > > to remember seeing such advise somewhere. > > However there is not even a function declaration with !CONFIG_THERMAL. > > So I can add an actual stub for it for v2. > > > > What do you think? > > > You mean an extern declaration without the actual function ? Stub as in empty inline function: static inline void thermal_zone_device_update(struct thermal_zone_device *, enum thermal_notify_event) { } > I'd really want to see that documented. It would seem rather unusual. From Documentation/process/coding-style.rst 21) Conditional Compilation --------------------------- Wherever possible, don't use preprocessor conditionals (#if, #ifdef) in .c files; doing so makes code harder to read and logic harder to follow. Instead, use such conditionals in a header file defining functions for use in those .c files, providing no-op stub versions in the #else case, and then call those functions unconditionally from .c files. The compiler will avoid generating any code for the stub calls, producing identical results, but the logic will remain easy to follow. [..] Within code, where possible, use the IS_ENABLED macro to convert a Kconfig symbol into a C boolean expression, and use it in a normal C conditional: .. code-block:: c if (IS_ENABLED(CONFIG_SOMETHING)) { ... } The compiler will constant-fold the conditional away, and include or exclude the block of code just as with an #ifdef, so this will not add any runtime overhead. [..] While this primarily talks about stubs, the fact that "the compiler will constant-fold the conditional away" can be understood that the linker will never see those function calls and therefore the functions don't have to be present during linking. So a declaration would be enough. But an actual stub doesn't hurt either. > Besides, there are several other #ifdefs in the same file, so I am not > as much bothered about this as you are. Your choice. If you want I can try to get rid of those, too. Thomas
On 11/13/24 23:27, Thomas Weißschuh wrote: > On 2024-11-13 22:51:37-0800, Guenter Roeck wrote: >> On 11/13/24 20:40, Thomas Weißschuh wrote: >>> On 2024-11-12 22:52:36-0800, Guenter Roeck wrote: >>>> On 11/12/24 20:39, Thomas Weißschuh wrote: >>>>> Using an #ifdef in a C source files to have different definitions >>>>> of the same symbol makes the code harder to read and understand. >>>>> Furthermore it makes it harder to test compilation of the different >>>>> branches. >>>>> >>>>> Replace the ifdeffery with IS_ENABLED() which is just a normal >>>>> conditional. >>>>> The resulting binary is still the same as before as the compiler >>>>> optimizes away all the unused code and definitions. >>>>> >>>>> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> >>>>> --- >>>>> This confused me a bit while looking at the implementation of >>>>> HWMON_C_REGISTER_TZ. >>>>> --- >>>>> drivers/hwmon/hwmon.c | 21 ++++++--------------- >>>>> 1 file changed, 6 insertions(+), 15 deletions(-) >>>>> >>>>> diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c >>>>> index 9c35c4d0369d7aad7ea61ccd25f4f63fc98b9e02..86fb674c85d3f54d475be014c3fd3dd74c815c57 100644 >>>>> --- a/drivers/hwmon/hwmon.c >>>>> +++ b/drivers/hwmon/hwmon.c >>>>> @@ -147,11 +147,6 @@ static DEFINE_IDA(hwmon_ida); >>>>> /* Thermal zone handling */ >>>>> -/* >>>>> - * The complex conditional is necessary to avoid a cyclic dependency >>>>> - * between hwmon and thermal_sys modules. >>>>> - */ >>>>> -#ifdef CONFIG_THERMAL_OF >>>>> static int hwmon_thermal_get_temp(struct thermal_zone_device *tz, int *temp) >>>>> { >>>>> struct hwmon_thermal_data *tdata = thermal_zone_device_priv(tz); >>>>> @@ -257,6 +252,9 @@ static int hwmon_thermal_register_sensors(struct device *dev) >>>>> void *drvdata = dev_get_drvdata(dev); >>>>> int i; >>>>> + if (!IS_ENABLED(CONFIG_THERMAL_OF)) >>>>> + return 0; >>>>> + >>>>> for (i = 1; info[i]; i++) { >>>>> int j; >>>>> @@ -285,6 +283,9 @@ static void hwmon_thermal_notify(struct device *dev, int index) >>>>> struct hwmon_device *hwdev = to_hwmon_device(dev); >>>>> struct hwmon_thermal_data *tzdata; >>>>> + if (!IS_ENABLED(CONFIG_THERMAL_OF)) >>>>> + return; >>>>> + >>>>> list_for_each_entry(tzdata, &hwdev->tzdata, node) { >>>>> if (tzdata->index == index) { >>>>> thermal_zone_device_update(tzdata->tzd, >>>> >>>> There is no dummy function for thermal_zone_device_update(). >>>> I really don't want to trust the compiler/linker to remove that code >>>> unless someone points me to a document explaining that it is guaranteed >>>> to not cause any problems. >>> >>> I'm fairly sure that a declaration should be enough, and believe >>> to remember seeing such advise somewhere. >>> However there is not even a function declaration with !CONFIG_THERMAL. >>> So I can add an actual stub for it for v2. >>> >>> What do you think? >>> >> You mean an extern declaration without the actual function ? > > Stub as in empty inline function: > > static inline void thermal_zone_device_update(struct thermal_zone_device *, > enum thermal_notify_event) > { } > Sure, that would work, but it would have to be declared in the thermal subsystem. >> I'd really want to see that documented. It would seem rather unusual. > >>From Documentation/process/coding-style.rst > > 21) Conditional Compilation > --------------------------- > > Wherever possible, don't use preprocessor conditionals (#if, #ifdef) in .c > files; doing so makes code harder to read and logic harder to follow. Instead, > use such conditionals in a header file defining functions for use in those .c > files, providing no-op stub versions in the #else case, and then call those > functions unconditionally from .c files. The compiler will avoid generating > any code for the stub calls, producing identical results, but the logic will > remain easy to follow. > > [..] > > Within code, where possible, use the IS_ENABLED macro to convert a Kconfig > symbol into a C boolean expression, and use it in a normal C conditional: > > .. code-block:: c > > if (IS_ENABLED(CONFIG_SOMETHING)) { > ... > } > > The compiler will constant-fold the conditional away, and include or exclude > the block of code just as with an #ifdef, so this will not add any runtime > overhead. > > [..] > > While this primarily talks about stubs, the fact that > "the compiler will constant-fold the conditional away" can be understood > that the linker will never see those function calls and therefore the > functions don't have to be present during linking. Yes, I am aware of that. However, that is not a formal language definition. Yes, in normal builds with a modern compiler it will be optimized away. However, I don't think that will happen if the kernel is built with -O0. > So a declaration would be enough. But an actual stub doesn't hurt either. > I disagree. You did not point to a formal language definition saying that dead code shall be optimized away and that functions called by such dead code don't have to actually exist. Do we really have to argue about this ? Please provide examples from elsewhere in the kernel which implement what you have suggested (not just the use of IS_ENABLED(), but the call to functions without stub which don't exist if the code is not enabled), and we can go from there. Thanks, Guenter
On 2024-11-14 06:40:03-0800, Guenter Roeck wrote: > On 11/13/24 23:27, Thomas Weißschuh wrote: > > On 2024-11-13 22:51:37-0800, Guenter Roeck wrote: > > > On 11/13/24 20:40, Thomas Weißschuh wrote: > > > > On 2024-11-12 22:52:36-0800, Guenter Roeck wrote: > > > > > On 11/12/24 20:39, Thomas Weißschuh wrote: > > > > > > Using an #ifdef in a C source files to have different definitions > > > > > > of the same symbol makes the code harder to read and understand. > > > > > > Furthermore it makes it harder to test compilation of the different > > > > > > branches. > > > > > > > > > > > > Replace the ifdeffery with IS_ENABLED() which is just a normal > > > > > > conditional. > > > > > > The resulting binary is still the same as before as the compiler > > > > > > optimizes away all the unused code and definitions. > > > > > > > > > > > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > > > > > > --- > > > > > > This confused me a bit while looking at the implementation of > > > > > > HWMON_C_REGISTER_TZ. > > > > > > --- > > > > > > drivers/hwmon/hwmon.c | 21 ++++++--------------- > > > > > > 1 file changed, 6 insertions(+), 15 deletions(-) > > > > > > > > > > > > diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c > > > > > > index 9c35c4d0369d7aad7ea61ccd25f4f63fc98b9e02..86fb674c85d3f54d475be014c3fd3dd74c815c57 100644 > > > > > > --- a/drivers/hwmon/hwmon.c > > > > > > +++ b/drivers/hwmon/hwmon.c > > > > > > @@ -147,11 +147,6 @@ static DEFINE_IDA(hwmon_ida); > > > > > > /* Thermal zone handling */ > > > > > > -/* > > > > > > - * The complex conditional is necessary to avoid a cyclic dependency > > > > > > - * between hwmon and thermal_sys modules. > > > > > > - */ > > > > > > -#ifdef CONFIG_THERMAL_OF > > > > > > static int hwmon_thermal_get_temp(struct thermal_zone_device *tz, int *temp) > > > > > > { > > > > > > struct hwmon_thermal_data *tdata = thermal_zone_device_priv(tz); > > > > > > @@ -257,6 +252,9 @@ static int hwmon_thermal_register_sensors(struct device *dev) > > > > > > void *drvdata = dev_get_drvdata(dev); > > > > > > int i; > > > > > > + if (!IS_ENABLED(CONFIG_THERMAL_OF)) > > > > > > + return 0; > > > > > > + > > > > > > for (i = 1; info[i]; i++) { > > > > > > int j; > > > > > > @@ -285,6 +283,9 @@ static void hwmon_thermal_notify(struct device *dev, int index) > > > > > > struct hwmon_device *hwdev = to_hwmon_device(dev); > > > > > > struct hwmon_thermal_data *tzdata; > > > > > > + if (!IS_ENABLED(CONFIG_THERMAL_OF)) > > > > > > + return; > > > > > > + > > > > > > list_for_each_entry(tzdata, &hwdev->tzdata, node) { > > > > > > if (tzdata->index == index) { > > > > > > thermal_zone_device_update(tzdata->tzd, > > > > > > > > > > There is no dummy function for thermal_zone_device_update(). > > > > > I really don't want to trust the compiler/linker to remove that code > > > > > unless someone points me to a document explaining that it is guaranteed > > > > > to not cause any problems. > > > > > > > > I'm fairly sure that a declaration should be enough, and believe > > > > to remember seeing such advise somewhere. > > > > However there is not even a function declaration with !CONFIG_THERMAL. > > > > So I can add an actual stub for it for v2. > > > > > > > > What do you think? > > > > > > > You mean an extern declaration without the actual function ? > > > > Stub as in empty inline function: > > > > static inline void thermal_zone_device_update(struct thermal_zone_device *, > > enum thermal_notify_event) > > { } > > > > Sure, that would work, but it would have to be declared in the thermal subsystem. Of course. > > > I'd really want to see that documented. It would seem rather unusual. > > > > > From Documentation/process/coding-style.rst > > > > 21) Conditional Compilation > > --------------------------- > > > > Wherever possible, don't use preprocessor conditionals (#if, #ifdef) in .c > > files; doing so makes code harder to read and logic harder to follow. Instead, > > use such conditionals in a header file defining functions for use in those .c > > files, providing no-op stub versions in the #else case, and then call those > > functions unconditionally from .c files. The compiler will avoid generating > > any code for the stub calls, producing identical results, but the logic will > > remain easy to follow. > > > > [..] > > > > Within code, where possible, use the IS_ENABLED macro to convert a Kconfig > > symbol into a C boolean expression, and use it in a normal C conditional: > > > > .. code-block:: c > > > > if (IS_ENABLED(CONFIG_SOMETHING)) { > > ... > > } > > > > The compiler will constant-fold the conditional away, and include or exclude > > the block of code just as with an #ifdef, so this will not add any runtime > > overhead. > > > > [..] > > > > While this primarily talks about stubs, the fact that > > "the compiler will constant-fold the conditional away" can be understood > > that the linker will never see those function calls and therefore the > > functions don't have to be present during linking. > > Yes, I am aware of that. However, that is not a formal language definition. Formal as in ANSI/ISO? I don't think these ever say anything about optimizations. And also the compilers don't really write down the details AFAIK. > Yes, in normal builds with a modern compiler it will be optimized away. > However, I don't think that will happen if the kernel is built with -O0. The kernel is never built with -O0. It's either -O2 or -Os. It's a Kconfig choice between CC_OPTIMIZE_FOR_PERFORMANCE or CC_OPTIMIZE_FOR_SIZE, one is always enabled. This is not clear from the logic in Makefile. With -O0 more or less everything breaks. > > So a declaration would be enough. But an actual stub doesn't hurt either. > > > > I disagree. You did not point to a formal language definition saying that dead code > shall be optimized away and that functions called by such dead code don't have > to actually exist. > > Do we really have to argue about this ? Please provide examples from elsewhere > in the kernel which implement what you have suggested (not just the use of > IS_ENABLED(), but the call to functions without stub which don't exist > if the code is not enabled), and we can go from there. None of the hwmon functions have stubs if !CONFIG_HWMON, only declarations. And there are multiple drivers that use the pattern from above. One example from drivers/net/wireless/mediatek/mt76/mt7921/init.c static int mt7921_thermal_init(struct mt792x_phy *phy) { struct wiphy *wiphy = phy->mt76->hw->wiphy; struct device *hwmon; const char *name; if (!IS_REACHABLE(CONFIG_HWMON)) return 0; name = devm_kasprintf(&wiphy->dev, GFP_KERNEL, "mt7921_%s", wiphy_name(wiphy)); if (!name) return -ENOMEM; hwmon = devm_hwmon_device_register_with_groups(&wiphy->dev, name, phy, mt7921_hwmon_groups); return PTR_ERR_OR_ZERO(hwmon); } *But* the thermal subsystem is actually using stubs. So the same should be done for thermal_zone_device_update(). As mentioned before, my original claim that declarations of the thermal functions are already usable when !CONFIG_THERMAL was wrong. And if the thermal header is to be touched, it should as well be a stub for consistency. Given that there are already stubs for all kinds of thermal functions, this doesn't seem like it would be an issue. Thomas
Hi Thomas, On Wed, Nov 13, 2024 at 05:39:16AM +0100, Thomas Weißschuh wrote: > Using an #ifdef in a C source files to have different definitions > of the same symbol makes the code harder to read and understand. > Furthermore it makes it harder to test compilation of the different > branches. > > Replace the ifdeffery with IS_ENABLED() which is just a normal > conditional. > The resulting binary is still the same as before as the compiler > optimizes away all the unused code and definitions. > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > --- I decided to apply the patch despite my concerns about the lack of dummy functions. Let's see if it blows up in our face; if so, I'll revert it. Thanks, Guenter
On 2024-11-15 08:31:27-0800, Guenter Roeck wrote: > Hi Thomas, > > On Wed, Nov 13, 2024 at 05:39:16AM +0100, Thomas Weißschuh wrote: > > Using an #ifdef in a C source files to have different definitions > > of the same symbol makes the code harder to read and understand. > > Furthermore it makes it harder to test compilation of the different > > branches. > > > > Replace the ifdeffery with IS_ENABLED() which is just a normal > > conditional. > > The resulting binary is still the same as before as the compiler > > optimizes away all the unused code and definitions. > > > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > > --- > > I decided to apply the patch despite my concerns about the lack > of dummy functions. Let's see if it blows up in our face; if so, > I'll revert it. It will blow up because of the missing declaration/stub for thermal_zone_device_update() Thomas
On Fri, Nov 15, 2024 at 08:31:29AM -0800, Guenter Roeck wrote: > Hi Thomas, > > On Wed, Nov 13, 2024 at 05:39:16AM +0100, Thomas Weißschuh wrote: > > Using an #ifdef in a C source files to have different definitions > > of the same symbol makes the code harder to read and understand. > > Furthermore it makes it harder to test compilation of the different > > branches. > > > > Replace the ifdeffery with IS_ENABLED() which is just a normal > > conditional. > > The resulting binary is still the same as before as the compiler > > optimizes away all the unused code and definitions. > > > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > > --- > > I decided to apply the patch despite my concerns about the lack > of dummy functions. Let's see if it blows up in our face; if so, > I'll revert it. Ah, no, that didn't work, because if CONFIG_THERMAL=n there isn't even an external declaration for thermal_zone_device_update(). Guenter
On Fri, Nov 15, 2024 at 08:34:47AM -0800, Guenter Roeck wrote: > On Fri, Nov 15, 2024 at 08:31:29AM -0800, Guenter Roeck wrote: > > Hi Thomas, > > > > On Wed, Nov 13, 2024 at 05:39:16AM +0100, Thomas Weißschuh wrote: > > > Using an #ifdef in a C source files to have different definitions > > > of the same symbol makes the code harder to read and understand. > > > Furthermore it makes it harder to test compilation of the different > > > branches. > > > > > > Replace the ifdeffery with IS_ENABLED() which is just a normal > > > conditional. > > > The resulting binary is still the same as before as the compiler > > > optimizes away all the unused code and definitions. > > > > > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> > > > --- > > > > I decided to apply the patch despite my concerns about the lack > > of dummy functions. Let's see if it blows up in our face; if so, > > I'll revert it. > > Ah, no, that didn't work, because if CONFIG_THERMAL=n there isn't > even an external declaration for thermal_zone_device_update(). > allnoconfig+CONFIG_HWMON: drivers/hwmon//hwmon.c: In function ‘hwmon_thermal_notify’: drivers/hwmon//hwmon.c:302:25: error: implicit declaration of function ‘thermal_zone_device_update’; did you mean ‘thermal_zone_device_disable’? [-Werror=implicit-function-declaration] 302 | thermal_zone_device_update(tzdata->tzd, Guenter
diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c index 9c35c4d0369d7aad7ea61ccd25f4f63fc98b9e02..86fb674c85d3f54d475be014c3fd3dd74c815c57 100644 --- a/drivers/hwmon/hwmon.c +++ b/drivers/hwmon/hwmon.c @@ -147,11 +147,6 @@ static DEFINE_IDA(hwmon_ida); /* Thermal zone handling */ -/* - * The complex conditional is necessary to avoid a cyclic dependency - * between hwmon and thermal_sys modules. - */ -#ifdef CONFIG_THERMAL_OF static int hwmon_thermal_get_temp(struct thermal_zone_device *tz, int *temp) { struct hwmon_thermal_data *tdata = thermal_zone_device_priv(tz); @@ -257,6 +252,9 @@ static int hwmon_thermal_register_sensors(struct device *dev) void *drvdata = dev_get_drvdata(dev); int i; + if (!IS_ENABLED(CONFIG_THERMAL_OF)) + return 0; + for (i = 1; info[i]; i++) { int j; @@ -285,6 +283,9 @@ static void hwmon_thermal_notify(struct device *dev, int index) struct hwmon_device *hwdev = to_hwmon_device(dev); struct hwmon_thermal_data *tzdata; + if (!IS_ENABLED(CONFIG_THERMAL_OF)) + return; + list_for_each_entry(tzdata, &hwdev->tzdata, node) { if (tzdata->index == index) { thermal_zone_device_update(tzdata->tzd, @@ -293,16 +294,6 @@ static void hwmon_thermal_notify(struct device *dev, int index) } } -#else -static int hwmon_thermal_register_sensors(struct device *dev) -{ - return 0; -} - -static void hwmon_thermal_notify(struct device *dev, int index) { } - -#endif /* IS_REACHABLE(CONFIG_THERMAL) && ... */ - static int hwmon_attr_base(enum hwmon_sensor_types type) { if (type == hwmon_in || type == hwmon_intrusion)
Using an #ifdef in a C source files to have different definitions of the same symbol makes the code harder to read and understand. Furthermore it makes it harder to test compilation of the different branches. Replace the ifdeffery with IS_ENABLED() which is just a normal conditional. The resulting binary is still the same as before as the compiler optimizes away all the unused code and definitions. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> --- This confused me a bit while looking at the implementation of HWMON_C_REGISTER_TZ. --- drivers/hwmon/hwmon.c | 21 ++++++--------------- 1 file changed, 6 insertions(+), 15 deletions(-) --- base-commit: 3022e9d00ebec31ed435ae0844e3f235dba998a9 change-id: 20241113-hwmon-thermal-2d2da581c276 Best regards,