linux-kernel - Re: [RFC PATCH] kbuild: Allow specifying some base host CFLAGS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK7LNAQ4Y1FR=YEjb1Tf6AT=qBne9+s-_-qwmijq75Z9OZWJZw@mail.gmail.com>
Date:   Thu, 19 Oct 2017 01:45:28 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Douglas Anderson <dianders@...omium.org>
Cc:     Guenter Roeck <groeck@...omium.org>, vapier@...omium.org,
        Matthias Kaehlcke <mka@...omium.org>, dtor@...omium.org,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        Michal Marek <michal.lkml@...kovi.net>
Subject: Re: [RFC PATCH] kbuild: Allow specifying some base host CFLAGS

2017-10-14 3:02 GMT+09:00 Douglas Anderson <dianders@...omium.org>:
> Right now there is a way to add some CFLAGS that affect target builds,
> but no way to add CFLAGS that affect host builds.  Let's add a way.
> We'll document two environment variables: CFLAGS_HOST and
> CXXFLAGS_HOST.
>
> We'll document that these variables get appended to by the kernel to
> make the final CFLAGS.  That means that, though the environment can
> specify some flags, if there is a conflict the kernel can override and
> win.  This works differently than KCFLAGS which is appended (and thus
> can override) the kernel specified CFLAGS.
>
> Why would I make KCFLAGS and CFLAGS_HOST work differently in this way?
> My argument is that it's about expected usage.  Typically the build
> system invoking the kernel has some idea about some basic CFLAGS that
> it wants to use to build things for the host and things for the
> target.  In general the build system would expect that its flags can
> be overridden if necessary (perhaps we need to turn off a warning when
> compiling a certain file, for instance).  So, all other things being
> equal, the way I'm making CFLAGS_HOST is the way I'd expect things to
> work.
>
> So, if it's expected that the build system can pass in a base set of
> flags, why didn't we make KCFLAGS work that way?  The short answer is:
> when building for the target the kernel is just "special".  The build
> system's "target" CFLAGS are likely intended for userspace programs
> and likely make very little sense to use as a basis.  This was talked
> about in the seminal commit 69ee0b352242 ("kbuild: do not pick up
> CFLAGS from the environment").  Basically: if the build system REALLY
> knows what it's doing then it can pass in flags that the kernel will
> use, but otherwise it should butt out.  Presumably this build system
> that really knows what it's doing knows better than the kernel so
> KCFLAGS comes after the kernel's normal flags.
>
> One last note: I chose to add new variables rather than just having
> the build system try to pass HOSTCFLAGS in somehow (either through the
> environment or the command line) to avoid weird interactions with
> recursive invocations of make.
>
> Signed-off-by: Douglas Anderson <dianders@...omium.org>
> ---

I'd like to know for-instance cases where this is useful.







-- 
Best Regards
Masahiro Yamada