Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1414829 > unrolled thread

[PATCH] kconfig.h: use already defined macros for IS_REACHABLE() define

Started byMasahiro Yamada <yamada.masahiro@socionext.com>
First post2016-06-06 11:30 +0200
Last post2016-06-07 00:10 +0200
Articles 4 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] kconfig.h: use already defined macros for IS_REACHABLE() define Masahiro Yamada <yamada.masahiro@socionext.com> - 2016-06-06 11:30 +0200
    Re: [PATCH] kconfig.h: use already defined macros for IS_REACHABLE() define Linus Torvalds <torvalds@linux-foundation.org> - 2016-06-06 18:40 +0200
      Re: [PATCH] kconfig.h: use already defined macros for IS_REACHABLE() define Masahiro Yamada <yamada.masahiro@socionext.com> - 2016-06-06 23:50 +0200
        Re: [PATCH] kconfig.h: use already defined macros for IS_REACHABLE()  define Nicolas Pitre <nicolas.pitre@linaro.org> - 2016-06-07 00:10 +0200

#1414829 — [PATCH] kconfig.h: use already defined macros for IS_REACHABLE() define

FromMasahiro Yamada <yamada.masahiro@socionext.com>
Date2016-06-06 11:30 +0200
Subject[PATCH] kconfig.h: use already defined macros for IS_REACHABLE() define
Message-ID<rGZ18-2XO-31@gated-at.bofh.it>
For the same reason as commit 02d699f1f464 ("include/linux/kconfig.h:
ese macros which are already defined"), it is better to use macros
IS_BUILTIN() and IS_MODULE() for defining IS_REACHABLE().

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---

 include/linux/kconfig.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h
index b33c779..e0182e1 100644
--- a/include/linux/kconfig.h
+++ b/include/linux/kconfig.h
@@ -41,8 +41,8 @@
  * This is similar to IS_ENABLED(), but returns false when invoked from
  * built-in code when CONFIG_FOO is set to 'm'.
  */
-#define IS_REACHABLE(option) (config_enabled(option) || \
-		 (config_enabled(option##_MODULE) && config_enabled(MODULE)))
+#define IS_REACHABLE(option) (IS_BUILTIN(option) || \
+		 (IS_MODULE(option) && config_enabled(MODULE)))
 
 /*
  * IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y' or 'm',
-- 
1.9.1

[toc] | [next] | [standalone]


#1415270

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2016-06-06 18:40 +0200
Message-ID<rH5Jf-7nV-9@gated-at.bofh.it>
In reply to#1414829
Side note:

On Mon, Jun 6, 2016 at 2:28 AM, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> -#define IS_REACHABLE(option) (config_enabled(option) || \
> -                (config_enabled(option##_MODULE) && config_enabled(MODULE)))
> +#define IS_REACHABLE(option) (IS_BUILTIN(option) || \
> +                (IS_MODULE(option) && config_enabled(MODULE)))

Is that "config_enabled(MODULE)" actually sensible?

The whole "config_enabled()" thing is designed for config options. But
"MODULE" is not a config option, it's per-file build option ("are we
now building for a module" vs "are we building built-in code").

The code clearly works, but it smells a bit confusing to me. Talking
about "config" of MODULE makes me think CONFIG_MODULES ("are modular
builds enabled") rather than "am I currently building a module".

I wonder if we should have something like

  #ifdef MODULE
   #define BUILDING_MODULES 1
  #else
   #define BUILDING_MODULES 0
  #endif

and then using (IS_MODULE(option) && BUILDING_MODULES) to clarify the test.

Because when I first looked at the patch and didn't think about it any
more, my initial reaction was "why is it checking whether modules are
enabled - if IS_MODULE() is true, then _obviously_ modules are
enabled?"

But maybe that's just me.

               Linus

[toc] | [prev] | [next] | [standalone]


#1415499

FromMasahiro Yamada <yamada.masahiro@socionext.com>
Date2016-06-06 23:50 +0200
Message-ID<rHazf-1ZA-7@gated-at.bofh.it>
In reply to#1415270
Hi Linus,


2016-06-07 1:36 GMT+09:00 Linus Torvalds <torvalds@linux-foundation.org>:
> Side note:
>
> On Mon, Jun 6, 2016 at 2:28 AM, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
>>
>> -#define IS_REACHABLE(option) (config_enabled(option) || \
>> -                (config_enabled(option##_MODULE) && config_enabled(MODULE)))
>> +#define IS_REACHABLE(option) (IS_BUILTIN(option) || \
>> +                (IS_MODULE(option) && config_enabled(MODULE)))
>
> Is that "config_enabled(MODULE)" actually sensible?
>
> The whole "config_enabled()" thing is designed for config options. But
> "MODULE" is not a config option, it's per-file build option ("are we
> now building for a module" vs "are we building built-in code").

I thought of this, too.

Because config_enabled() is so useful,
maybe people tend to abuse it.


I see one case where config_enabled() is used
for a non-config macro.


#define __EXPORT_SYMBOL(sym, sec) \
           __cond_export_sym(sym, sec, config_enabled(__KSYM_##sym))

Assuming we can do something with that,
ultimately I'd like to ban the use of
config_enabled() outside of include/linux/kconfig.h

I already started this work:
http://www.spinics.net/lists/mips/msg63759.html




> The code clearly works, but it smells a bit confusing to me. Talking
> about "config" of MODULE makes me think CONFIG_MODULES ("are modular
> builds enabled") rather than "am I currently building a module".
>
> I wonder if we should have something like
>
>   #ifdef MODULE
>    #define BUILDING_MODULES 1
>   #else
>    #define BUILDING_MODULES 0
>   #endif
>
> and then using (IS_MODULE(option) && BUILDING_MODULES) to clarify the test.


MODULE is defined / undefined per file.

So, I think BUILDING_MODULE makes more sense than BUILDING_MODULES.



> Because when I first looked at the patch and didn't think about it any
> more, my initial reaction was "why is it checking whether modules are
> enabled - if IS_MODULE() is true, then _obviously_ modules are
> enabled?"
>
> But maybe that's just me.
>
>                Linus



-- 
Best Regards
Masahiro Yamada

[toc] | [prev] | [next] | [standalone]


#1415512 — Re: [PATCH] kconfig.h: use already defined macros for IS_REACHABLE() define

FromNicolas Pitre <nicolas.pitre@linaro.org>
Date2016-06-07 00:10 +0200
SubjectRe: [PATCH] kconfig.h: use already defined macros for IS_REACHABLE() define
Message-ID<rHaSB-2px-17@gated-at.bofh.it>
In reply to#1415499
On Tue, 7 Jun 2016, Masahiro Yamada wrote:

> Because config_enabled() is so useful,
> maybe people tend to abuse it.
> 
> I see one case where config_enabled() is used
> for a non-config macro.
> 
> #define __EXPORT_SYMBOL(sym, sec) \
>            __cond_export_sym(sym, sec, config_enabled(__KSYM_##sym))

Here the need is for a macro that returns 1 or 0 whether given 
symbol is defined or not, exactly as explained in the comment above the 
definition for config_enabled() which in itself has nothing to do with 
config.

So maybe config_enabled() should be renamed to __is_defined() or 
similar, and then config_enabled() or its replacement defined in termps 
of it.


Nicolas

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web