From: Masahiro Yamada <masahiroy@kernel.org>
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
Subject: Re: Linux 6.3-rc3
Date: Sat, 25 Mar 2023 02:16:43 +0900 [thread overview]
Message-ID: <CAK7LNATe7Ah-ow9wYGrtL9i4z-VD=MCo=sJjbC_S0ofEoH6CFQ@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=whdrvCkSWh=BRrwZwNo3=yLBXXM88NGx8VEpP1VTgmkyQ@mail.gmail.com>
Hello Linus,
Thanks for giving me some more homeworks.
On Thu, Mar 23, 2023 at 1:56 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Wed, Mar 22, 2023 at 9:40 AM Sedat Dilek <sedat.dilek@gmail.com> wrote:
> >
> > You have to pass `make LLVM=1` 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=i386 allmodconfig
>
> to build the .config file, but then you have to *repeat* that
> ARCH=i386 when you actually build things:
>
> make ARCH=i386
>
> 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= 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= 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
next prev parent reply other threads:[~2023-03-24 17:18 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-19 20:50 Linux 6.3-rc3 Linus Torvalds
2023-03-20 8:21 ` Build regressions/improvements in v6.3-rc3 Geert Uytterhoeven
2023-03-21 5:38 ` Build regressions/improvements in v6.3-rc3 (drm/msm/) Randy Dunlap
2023-03-21 7:34 ` Geert Uytterhoeven
2023-03-21 15:10 ` Randy Dunlap
2023-03-21 15:33 ` Geert Uytterhoeven
2023-03-20 18:05 ` Linux 6.3-rc3 Nathan Chancellor
2023-03-20 18:26 ` Linus Torvalds
2023-03-20 18:49 ` Linus Torvalds
2023-03-20 18:56 ` Nathan Chancellor
2023-03-20 19:05 ` Linus Torvalds
2023-03-20 18:53 ` Nathan Chancellor
2023-03-20 19:22 ` Nathan Chancellor
2023-03-22 12:44 ` Kalle Valo
2023-03-22 16:36 ` Nathan Chancellor
2023-03-22 20:36 ` Nathan Chancellor
2023-03-24 10:54 ` Kalle Valo
2023-03-24 15:11 ` Nathan Chancellor
2023-03-24 15:23 ` Kalle Valo
2023-03-28 19:07 ` Nathan Chancellor
2023-03-29 8:39 ` Kalle Valo
2023-03-22 16:40 ` Sedat Dilek
2023-03-22 16:55 ` Linus Torvalds
2023-03-22 18:17 ` Nick Desaulniers
2023-03-24 17:16 ` Masahiro Yamada [this message]
2023-03-27 16:12 ` Jani Nikula
2023-03-27 17:03 ` Kalle Valo
2023-03-20 20:04 ` Guenter Roeck
2023-03-20 20:30 ` Linus Torvalds
2023-03-20 22:06 ` Nathan Chancellor
2023-03-20 22:48 ` Segher Boessenkool
2023-03-20 23:41 ` Linus Torvalds
2023-03-24 9:41 ` Daniel Vetter
2023-03-20 20:07 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAK7LNATe7Ah-ow9wYGrtL9i4z-VD=MCo=sJjbC_S0ofEoH6CFQ@mail.gmail.com' \
--to=masahiroy@kernel.org \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=nathan@kernel.org \
--cc=sedat.dilek@gmail.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).