[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VdZ67Tab2jOU0NSys_P1rU_GicJw_ADd1w9JY4rEG5g1w@mail.gmail.com>
Date: Fri, 9 Apr 2021 12:24:23 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>,
Paul Cercueil <paul@...pouillou.net>,
Linus Walleij <linus.walleij@...aro.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-mips@...r.kernel.org
Subject: Re: [PATCH 1/2] linux/kconfig.h: replace IF_ENABLED() with PTR_IF()
in <linux/kernel.h>
On Fri, Apr 9, 2021 at 12:00 AM Masahiro Yamada <masahiroy@...nel.org> wrote:
>
> <linux/kconfig.h> is included from all the kernel-space source files,
> including C, assembly, linker scripts. It is intended to contain minimal
a minimal
> set of macros to evaluate CONFIG options.
>
> IF_ENABLED() is an intruder here because (x ? y : z) is C code, which
> should not be included from assembly files or linker scripts.
>
> Also, <linux/kconfig.h> is no longer self-contained because NULL is
> defined in <linux/stddef.h>.
>
> Move IF_ENABLED() out to <linux/kernel.h> as PTR_IF().
>
> PTR_IF(IS_ENABLED(CONFIG_FOO), ...) is slightly longer than
> IF_ENABLED(CONFIG_FOO, ...), but it is not a big deal because
> sub-systems often define dedicated macros such as of_match_ptr(),
> pm_ptr() etc. for common use-cases.
> include/linux/kernel.h | 2 ++
Why kernel.h? Shouldn't it belong to a particular domain with a
respective header file?
Really what we have in the kernel.h right now is a complete train
wreck of something.
We have to define what exactly is kernel.h for?
Arnd? Others? Shall we start a wider discussion on the topic?
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists