Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAHk-=wiPd8R8-zSqTOtJ9KYeZLBByHug7ny3rgP-ZqzpP_KELg@mail.gmail.com>
 <20230320180501.GA598084@dev-arch.thelio-3990X> <CAHk-=wgSqpdkeJBb92M37JNTdRQJRnRUApraHKE8uGHTqQuu2Q@mail.gmail.com>
 <20230320185337.GA615556@dev-arch.thelio-3990X> <87pm91uf9c.fsf@kernel.org>
 <CA+icZUUYyqhV2HFzVtpi_KjBoYxjk7OB0UBVd2mX6abjmYhDjg@mail.gmail.com> <CAHk-=whdrvCkSWh=BRrwZwNo3=yLBXXM88NGx8VEpP1VTgmkyQ@mail.gmail.com>
In-Reply-To: <CAHk-=whdrvCkSWh=BRrwZwNo3=yLBXXM88NGx8VEpP1VTgmkyQ@mail.gmail.com>
From:   Masahiro Yamada <masahiroy@kernel.org>
Date:   Sat, 25 Mar 2023 02:16:43 +0900
Message-ID: <CAK7LNATe7Ah-ow9wYGrtL9i4z-VD=MCo=sJjbC_S0ofEoH6CFQ@mail.gmail.com>
Subject: Re: Linux 6.3-rc3
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     sedat.dilek@gmail.com, Kalle Valo <kvalo@kernel.org>,
        Nathan Chancellor <nathan@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        David Airlie <airlied@gmail.com>,
        Daniel Vetter <daniel@ffwll.ch>,
        dri-devel@lists.freedesktop.org, linux-toolchains@vger.kernel.org,
        llvm@lists.linux.dev
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hello Linus,


Thanks for giving me some more homeworks.


On Thu, Mar 23, 2023 at 1:56=E2=80=AFAM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Wed, Mar 22, 2023 at 9:40=E2=80=AFAM Sedat Dilek <sedat.dilek@gmail.co=
m> wrote:
> >
> > You have to pass `make LLVM=3D1` in any case... to `oldconfig` or when
> > adding any MAKEFLAGS like -j${number-of-available-cpus}.
>
> I actually think we should look (again) at just making the compiler
> choice (and the prefix) be a Kconfig option.
>
> That would simplify *so* many use cases.
>
> It used to be that gcc was "THE compiler" and anything else was just
> an odd toy special case, but that's clearly not true any more.
>
> So it would be lovely to make the kernel choice a Kconfig choice - so
> you'd set it only at config time, and then after that a kernel build
> wouldn't need special flags any more, and you'd never need to play
> games with GNUmakefile or anything like that.


Presumably, this is the right direction.

To achieve it, Kconfig needs to have some mechanism to evaluate
shell commands dynamically.

If a user switches the toolchain set between GCC and LLVM
while running the Kconfig, $(cc-option) in Kconfig files must
be re-calculated.

Currently, Kconfig cannot do it. All macros are static - they are
expanded in the parse stage, and become constant strings.

Ulf Magnusson and I discussed the dynamic approach a few years back,
but I adopted the static way since it is much simpler.
We need to reconsider the dynamic approach to do this correctly.
I do not think it is too difficult technically.
We just need to come up with a decent syntax.


> Yes, you'd still use environment variables (or make arguments) for
> that initial Kconfig, but that's no different from the other
> environment variables we already have, like KCONFIG_SEED that kconfig
> uses internally, but also things like "$(ARCH)" that we already use
> *inside* the Kconfig files themselves.
>
> I really dislike how you have to set ARCH and CROSS_COMPILE etc
> externally, and can't just have them *in* the config file.
>
> So when you do cross-compiles, right now you have to do something like
>
>     make ARCH=3Di386 allmodconfig
>
> to build the .config file, but then you have to *repeat* that
> ARCH=3Di386 when you actually build things:
>
>     make ARCH=3Di386
>
> because the ARCH choice ends up being in the .config file, but the
> makefiles themselves always take it from the environment.
>
> There are good historical reasons for our behavior (and probably a
> number of extant practical reasons too), but it's a bit annoying, and
> it would be lovely if we could start moving away from this model.
>
>             Linus


Moving ARCH into the .config file needs careful thoughts, I think.

Not all targets include the .config file.
For example, "make clean", "make help", etc.

It is unclear which targets require explicit ARCH=3D option.

One solution is to move "archhelp", "CLEAN_FILES" etc.
from arch/*/Makefile to the top Makefile.
We will lose per-arch splitting in several places, though.


U-Boot adopts this model - 'ARCH' is determined in the Kconfig time,
so users do not need to give ARCH=3D option from the command line.

https://github.com/u-boot/u-boot/blob/v2023.01/arch/Kconfig#L44

You may get a quick idea of what it will look like.


I will take a look at this direction (the compiler choice in Kconfig first)=
,
but it will not happen soonish due to the limited time for upstream work.


--
Best Regards

Masahiro Yamada