Re: [PATCH v3 10/20] kbuild: move the toolchain checks into init/Kconfig.toolchain
Nathan Chancellor <[email protected]>
| Newsgroups | org.kernel.vger.linux-doc,dev.linux.lists.llvm,org.infradead.lists.linux-riscv,org.kernel.vger.linux-arch,org.kernel.vger.linux-efi,org.kernel.vger.linux-hardening,org.kernel.vger.linux-kbuild,org.kernel.vger.linux-kernel,org.kernel.vger.rust-for-linux |
|---|---|
| Message-ID | <20260918010729.GB1585590@ax162> |
On Thu, Sep 17, 2026 at 11:53:13AM -0700, Kees Cook wrote: > On Thu, Sep 17, 2026 at 05:06:20PM +0100, Lorenzo Stoakes (ARM) wrote: > > Move them into their own file, sourced from the top of init/Kconfig, so > > that the next commit can add to them without growing init/Kconfig further. > > > > No functional change. > > > > Assisted-by: LLM > > Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]> > > --- > > init/Kconfig | 197 +----------------------------------------------- > > init/Kconfig.toolchain | 198 +++++++++++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 199 insertions(+), 196 deletions(-) > > Yeah, totally right to move to a separate file. I think, however, I > would prefer this wasn't in init/ though. Kbuild uses scripts/ as its > Makefile.$topic dumping ground, and Kconfig.include also lives there. To > me, this new file should be scripts/Kconfig.toolchain instead. And > arguably, this should be included by the top-level Kconfig rather than > init/Kconfig... > > I defer to kbuild folks, though. We talked about this previously: https://lore.kernel.org/aqPW1FsBVYHSWl1r@gremlin/ I do feel like scripts/ is a better location given that these are really things internal to Kbuild but I also see where Lorenzo is coming from that scripts/ is a little weird for this to live for discoverability, especially if we want people to put checks here instead of in a Makefile directly. To be honest, it would be kind of nice to separate the Kbuild parts of scripts into their own directory to make it clear what Kbuild uses versus what users/contributors should use but that is obviously too big of a project to tackle as a prerequisite for this. -- Cheers, Nathan