On Fri, Jan 23, 2026 at 5:05 AM Mikko Rapeli <[email protected]> wrote:
> Hi, > > On Fri, Jan 09, 2026 at 11:37:18AM -0500, Bruce Ashfield wrote: > > On Fri, Jan 9, 2026 at 10:35 AM Mikko Rapeli via lists.yoctoproject.org > > <[email protected]> wrote: > > > > > These get effectively disabled on other archs > > > and cause warnings from merge_config.sh. > > > > > > > And again, we can't make everything conditional, it > > will become very hard to maintain. So either those > > warnings are ignored (which is what my audit does > > in the builds), or they need to be in an arch specific > > fragment. > > > > Not everything should go into arch specific fragments > > or have conditionals, as I go back to that design decision > > to filter warnings to make the configuration stacks > > simpler. > > In numa this is one single x86 specific config among many > which are usable across archs. That is not much and can > be easily handled correctly. I'm not trying to move everything > or force everyone to do this but I would like genericarm64 > kernel config to be clean and not try to set x86 specific > options which end up getting disabled due to dependencies. > Understood, and I'm just saying that rather than conditional checks, doing an explicit split into an arch fragment and then having the arch/ .scc file include them scores better on discoverability as the choice is now obvious and implicitly documented. Which is pretty much what you've done, and I'm saying you've done the right thing. I'm just saying, hunt up an x86 specific location and put the include of both fragments in there or see if there are any references to it in KERNEL_FEATURES and update them to have both includes if they are x86. > > The tooling to detect these are currently outside in > patches to kernel kconfig side merge_config.sh but hopefully > they can be in yocto kernel/oe-core too. > I mentioned previously that sure, you can enable audit and change the tooling like that, but the purpose of the fragments is to serve many different stacks. That means there are design decisions about what goes where, and there are some options that get disabled a kernel config time.. and we are ok with that, as long as they aren't tagged hardware or required. The existing tooling has always been able to warn on everything that didn't make it into the final .config, but due to the above, it has never been enabled. I only use it when doing kernel uprevs or looking at what bitrot may have happened in the configuration stack. Bruce > > > https://lore.kernel.org/linux-kbuild/[email protected]/T/#t > > Cheers, > > -Mikko > > > Bruce > > > > > > > > > > > > Signed-off-by: Mikko Rapeli <[email protected]> > > > --- > > > features/numa/numa.cfg | 1 - > > > features/numa/numa.scc | 4 ++++ > > > features/numa/numa_x86_64.cfg | 2 ++ > > > 3 files changed, 6 insertions(+), 1 deletion(-) > > > create mode 100644 features/numa/numa_x86_64.cfg > > > > > > diff --git a/features/numa/numa.cfg b/features/numa/numa.cfg > > > index 2cf4bae2d3ae..2cb872a75ed4 100644 > > > --- a/features/numa/numa.cfg > > > +++ b/features/numa/numa.cfg > > > @@ -2,7 +2,6 @@ > > > CONFIG_NUMA=y > > > CONFIG_NUMA_BALANCING=y > > > CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y > > > -CONFIG_X86_64_ACPI_NUMA=y > > > CONFIG_NUMA_EMU=y > > > CONFIG_NODES_SHIFT=6 > > > CONFIG_USE_PERCPU_NUMA_NODE_ID=y > > > diff --git a/features/numa/numa.scc b/features/numa/numa.scc > > > index 854998b1b026..a53a68c23bee 100644 > > > --- a/features/numa/numa.scc > > > +++ b/features/numa/numa.scc > > > @@ -2,3 +2,7 @@ > > > define KFEATURE_DESCRIPTION "Enable numa support" > > > > > > kconf hardware numa.cfg > > > + > > > +if [ "$KARCH" = "x86_64" ]; then > > > + kconf hardware numa_x86_64.cfg > > > +fi > > > diff --git a/features/numa/numa_x86_64.cfg > b/features/numa/numa_x86_64.cfg > > > new file mode 100644 > > > index 000000000000..931c46e92040 > > > --- /dev/null > > > +++ b/features/numa/numa_x86_64.cfg > > > @@ -0,0 +1,2 @@ > > > +# SPDX-License-Identifier: MIT > > > +CONFIG_X86_64_ACPI_NUMA=y > > > -- > > > 2.34.1 > > > > > > > > > > > > > > > > > > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee > > at its end > > - "Use the force Harry" - Gandalf, Star Trek II > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#16206): https://lists.yoctoproject.org/g/linux-yocto/message/16206 Mute This Topic: https://lists.yoctoproject.org/mt/117176761/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
