From: Masahiro Yamada <masahiroy@kernel.org> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: linux-toolchains@vger.kernel.org, Kalle Valo <kvalo@kernel.org>, llvm@lists.linux.dev, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, dri-devel@lists.freedesktop.org, Nathan Chancellor <nathan@kernel.org>, sedat.dilek@gmail.com 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
WARNING: multiple messages have this Message-ID (diff)
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:17 UTC|newest] Thread overview: 65+ 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 5:38 ` Randy Dunlap 2023-03-21 7:34 ` Geert Uytterhoeven 2023-03-21 7:34 ` Geert Uytterhoeven 2023-03-21 15:10 ` Randy Dunlap 2023-03-21 15:10 ` Randy Dunlap 2023-03-21 15:33 ` Geert Uytterhoeven 2023-03-21 15:33 ` Geert Uytterhoeven 2023-03-20 18:05 ` Linux 6.3-rc3 Nathan Chancellor 2023-03-20 18:05 ` Nathan Chancellor 2023-03-20 18:26 ` Linus Torvalds 2023-03-20 18:26 ` Linus Torvalds 2023-03-20 18:49 ` Linus Torvalds 2023-03-20 18:49 ` Linus Torvalds 2023-03-20 18:56 ` Nathan Chancellor 2023-03-20 18:56 ` Nathan Chancellor 2023-03-20 19:05 ` Linus Torvalds 2023-03-20 19:05 ` Linus Torvalds 2023-03-20 18:53 ` Nathan Chancellor 2023-03-20 18:53 ` Nathan Chancellor 2023-03-20 19:22 ` Nathan Chancellor 2023-03-20 19:22 ` Nathan Chancellor 2023-03-22 12:44 ` Kalle Valo 2023-03-22 12:44 ` Kalle Valo 2023-03-22 16:36 ` Nathan Chancellor 2023-03-22 16:36 ` Nathan Chancellor 2023-03-22 20:36 ` Nathan Chancellor 2023-03-22 20:36 ` Nathan Chancellor 2023-03-24 10:54 ` Kalle Valo 2023-03-24 10:54 ` Kalle Valo 2023-03-24 15:11 ` Nathan Chancellor 2023-03-24 15:11 ` Nathan Chancellor 2023-03-24 15:23 ` Kalle Valo 2023-03-24 15:23 ` Kalle Valo 2023-03-28 19:07 ` Nathan Chancellor 2023-03-28 19:07 ` Nathan Chancellor 2023-03-29 8:39 ` Kalle Valo 2023-03-29 8:39 ` Kalle Valo 2023-03-22 16:40 ` Sedat Dilek 2023-03-22 16:40 ` Sedat Dilek 2023-03-22 16:55 ` Linus Torvalds 2023-03-22 16:55 ` Linus Torvalds 2023-03-22 18:17 ` Nick Desaulniers 2023-03-22 18:17 ` Nick Desaulniers 2023-03-24 17:16 ` Masahiro Yamada [this message] 2023-03-24 17:16 ` Masahiro Yamada 2023-03-27 16:12 ` Jani Nikula 2023-03-27 16:12 ` Jani Nikula 2023-03-27 17:03 ` Kalle Valo 2023-03-27 17:03 ` Kalle Valo 2023-03-20 20:04 ` Guenter Roeck 2023-03-20 20:04 ` Guenter Roeck 2023-03-20 20:30 ` Linus Torvalds 2023-03-20 20:30 ` Linus Torvalds 2023-03-20 22:06 ` Nathan Chancellor 2023-03-20 22:06 ` Nathan Chancellor 2023-03-20 22:48 ` Segher Boessenkool 2023-03-20 22:48 ` Segher Boessenkool 2023-03-20 23:41 ` Linus Torvalds 2023-03-20 23:41 ` Linus Torvalds 2023-03-24 9:41 ` Daniel Vetter 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=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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.