(In reply to comment #0)
> I also stumbled upon another interesting issue, which I described here[1].
> 
> I just tried to switch CONFIG_IMX_SDMA=y to CONFIG_IMX_SDMA=m, which should
> be an "out of the box" experience one would think.
> 
> I did 
> 1) bitbake virtual/kernel -c menuconfig, made the modification and 
> 2) bitbake virtual/kernel -c diffconfig produced a fragment[2]. 
> 
> So far all good!
> 
> I made a "dummy" scc file[3] as well and added it to my standard kernel
> config meta data[4], but it was ignored. CONFIG_IMX_SDMA stayed y - no
> apparent bad things spit out by kernel tooling. 
> 
> Since I just learned about KERNEL_FEATURES_append, which I successfully used
> to conditionally include kernel meta data[5] I gave that a try[6].
> 
> ... and it worked ...
> 
> Now I am a bit worried about all my other .scc/.cfg files. 
> 
> Will they all be applied? 

FWIW: I'm working on a significant update of kernel fragment tools right now, targeted for the upcoming release. They will answer questions like this.

The answer is yes, they will be applied, but if some other fragment or dependency requires that the symbol be =y, you'll get =y in the end kernel. If your KERNEL_FEATURE is tweaking that same dependency, and since it is applied last, it may show as a different final symbol.

> 
> Why is CONFIG_IMX_SDMA=m ignored when included my "usual" way via kernel
> types and .scc/.cfg files and not from KERNEL_FEATURES_append?

see above.

> 
> What you mentioned in bug13927[7] might be part of the
> explanation:"KERNEL_FEATURES come from the main kernel-cache, and are sanity
> checked for failure. They are also, by design, the last element applied to
> the merging process, since they signify a strict dependency.
> 
> SRC_URI fragments are merged and applied using the normal fragment rules."
> 
> When are .scc/.cfg fragments applied compared to the other 2 above. I guess
> with the "normal fragment rules" like with SRC_URI.
> 
> If you can give me a hint which variables to turn on and which logs to check
> to figure out why certain fragments are not applied it would help.
> 
> [1]
> https://gitlab.com/meta-layers/meta-multi-v7-ml-bsp/-/blob/dunfell/recipes-
> kernel/linux/linux-yocto-custom-common_5.4.inc#L34

The config.queue and merge-config logs are the files of most interest (in the current state of things, there will be better files soon).

config.queue is in the work-shared/$MACHINE/kernel-source/.kmeta/

and the merge-config artifacts are one directory deeper under cfg/


Bruce

> 
> [2]
> https://gitlab.com/meta-layers/meta-multi-v7-ml-bsp/-/blob/dunfell/recipes-
> kernel/linux/config/multi-v7-ml-base/features/imx-sdma/imx-sdma.cfg
> 
> [3]
> https://gitlab.com/meta-layers/meta-multi-v7-ml-bsp/-/blob/dunfell/recipes-
> kernel/linux/config/multi-v7-ml-base/features/imx-sdma/imx-sdma.scc
> 
> [4]
> https://gitlab.com/meta-layers/meta-multi-v7-ml-bsp/-/blob/dunfell/recipes-
> kernel/linux/config/multi-v7-ml-base/features-collection/std-collection.
> scc#L97
> 
> [5]
> https://gitlab.com/meta-layers/meta-multi-v7-ml-bsp/-/blob/dunfell/recipes-
> kernel/linux/linux-yocto-custom-common_5.4.inc#L21
> 
> [6]
> https://gitlab.com/meta-layers/meta-multi-v7-ml-bsp/-/blob/dunfell/recipes-
> kernel/linux/linux-yocto-custom-common_5.4.inc#L49
> 
> [7] https://bugzilla.yoctoproject.org/show_bug.cgi?id=13927

if you use my layers as described in bug13927 you can see the problem as follows:

the layer is: meta-multi-v7-ml-bsp

we want to apply

recipes-kernel/linux/config/multi-v7-ml-base/features/imx-sdma/imx-sdma.scc

which just sets CONFIG_IMX_SDMA=m

this works as it is right now because

recipes-kernel/linux/linux-yocto-custom-common_5.4.inc applies it:

KERNEL_FEATURES_append = " features/imx-sdma/imx-sdma.scc"

----

if you comment out the line above and in this file

recipes-kernel/linux/config/multi-v7-ml-base/features-collection/std-collection.scc

activate this line:

include features/imx-sdma/imx-sdma.scc

CONFIG_IMX_SDMA=m is not applied. it's =y

Thanks for the config update. I'm starting some configuration runs on this now.

the quick answer is .. you have a defconfig that contains that same option that is being applied after your fragment.

build2 [/home/bruc...ernel-meta]> findit -i '*' CONFIG_IMX_SDMA
./cfg/merge_config_build.log:Value of CONFIG_IMX_SDMA is redefined by fragment .kernel-meta/configs//./defconfig:
./cfg/merge_config_build.log:Previous value: CONFIG_IMX_SDMA=m
./cfg/merge_config_build.log:New value: CONFIG_IMX_SDMA=y
./configs/features/imx-sdma/imx-sdma.cfg:CONFIG_IMX_SDMA=m
./configs/defconfig:CONFIG_IMX_SDMA=y

And this is the config.queue:

configs//ktypes/virt/virt.cfg # non-hardware
configs//features/ikconfig/ikconfig.cfg # non-hardware
configs//features/posix-mqueue/posix-mqueue.cfg # non-hardware
configs//features/ramdisk/ramdisk.cfg # non-hardware
configs//features/mtd/mtd.cfg # non-hardware
configs//features/imx2-wdt/imx2-wdt.cfg # non-hardware
configs//features/gpmi-nand/gpmi-nand.cfg # non-hardware
configs//features/da9062-pmic/da9062-pmic.cfg # non-hardware
configs//features/snvs-rtc/snvs-rtc.cfg # non-hardware
configs//features/cyclonev-wdt/cyclonev-wdt.cfg # non-hardware
configs//features/zynq-qspi/zynq-qspi.cfg # non-hardware
configs//features/tun/tun.cfg # non-hardware
configs//features/btrfs/btrfs.cfg # non-hardware
configs//features/syn-cookies/syn-cookies.cfg # non-hardware
configs//features/imx-sdma/imx-sdma.cfg # non-hardware
configs//features/xt-checksum/xt-checksum.cfg # non-hardware
configs//features/ebtables/ebtables.cfg # non-hardware
configs//features/vswitch/vswitch.cfg # non-hardware
configs//features/lxc/lxc.cfg # non-hardware
configs//features/docker/docker.cfg # non-hardware
configs//features/btrfs/btrfs.cfg # non-hardware
configs//features/bridge/bridge.cfg # non-hardware
configs//features/netfilter/netfilter.cfg # non-hardware
configs//features/cgroups/cgroups.cfg # non-hardware
configs//features/namespaces/namespaces.cfg # non-hardware
configs//features/namespaces/namespaces-experimental.cfg # non-hardware
configs//features/ip6_nf/ip6_nf.cfg # non-hardware
configs//features/ip_nf/ip_nf.cfg # non-hardware
configs//features/ipsec/ipsec.cfg # non-hardware
configs//features/ipsec6/ipsec6.cfg # non-hardware
configs//features/ipsec/ipsec.cfg # non-hardware
configs//features/ipv6/ipv6.cfg # non-hardware
configs//features/ipsec/ipsec.cfg # non-hardware
configs//features/ipsec6/ipsec6.cfg # non-hardware
configs//./defconfig # non-hardware
configs//./xt-checksum.cfg # non-hardware
configs//./ebtables.cfg # non-hardware
configs//./vswitch.cfg # non-hardware
configs//./lxc.cfg # non-hardware
configs//./docker.cfg # non-hardware
configs//features/rtl8xxxu/rtl8xxxu.cfg # non-hardware
configs//cfg/virtio.cfg # non-hardware

So as you can see, the defconfig does come after the fragment. 

And it was logged during the merge as you can see from the first grep (also, these are the types of things that I'm exposing in my new work on making this easier to diagnose from the command line).

The bulk of your configs are properly setup in fragments, but since there has to be an order to things .. that order is causing a problem. The order of configs is:

  bsp_definition (your multi-config entry point)
  src_uri fragments (of which the KERNEL_DEFCONFIG is one, and that's where your defconfig comes from)
  KERNEL_FEATURES (as I mentioned, they get the last word)

And that fully explains why the value wasn't =m, and why doing it in KERNEL_FEATURES works.

I don't want to close this though, I want to think on it a bit more and see if there's a flexible way (like we have with SRCREV_format) to define the order in your recipe, so you can change this from a layer.

Thanks for the detailed analysis and I want your tools ;)

My understanding was (so far) that first the defconfig is being used and that fragments are being applied on top of it - at least that is what happens on a kernel.org kernel without Yocto magic. You throw all the fragments in some file and apply them against some defconfig - I need to test if I can change CONFIG_IMX_SDMA=y to CONFIG_IMX_SDMA=m with merge_config.sh[2].

Here is what I intend to do:

1) get in in-tree defconfig[1]

2) apply the fragments

3) apply KERNEL_FEATURES

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/configs/multi_v7_defconfig?h=v5.4.43

[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/scripts/kconfig/merge_config.sh?h=v5.4.43

Now what you are saying is, that with 2) fragments I am not able to change anything which was was already set in defconfig - which is new to me (and I guess I was lucky so far that it worked for me).

Apparently CONFIG items, which were not set in defconfig seem to work happily.

And I guess the only way to change things which were already set in a defconfig is to use KERNEL_FEATURES.

It works as you describe for a SRC_URI based defconfig, the processing for the ones we can pick out of the tree had that order chosen (by me).

As I mentioned, I'm going to move that order back to the beginning and then your fragments will work as expected.

But for now, keep things in kernel_features and I'll cc' you on the patch to change the order.

Created attachment 4689 [details]
patch under test

Attached is my proposed fix for this. It solves the problem here. I need to run a lot of regression tests to make sure I don't break anything, but it works for what I've been able to run so far.

Just out of curiosity when did "applying only fragments which are not in defconfig" happen?  

Is this from dunfell on or did it appear in some previous release as well?

I assume this change is significant and breaks a couple of things in a very subtle ways.

(In reply to comment #8)
> Just out of curiosity when did "applying only fragments which are not in
> defconfig" happen?  
> 
> Is this from dunfell on or did it appear in some previous release as well?
> 
> I assume this change is significant and breaks a couple of things in a very
> subtle ways.

It has pretty much always been that way.

But to be clear, there are no ignored fragments, but of course the order matters and that's what we are hitting here.

Let me rephrase:

1) If a configuration item (CONFIG_XXX) is already in defconfig it takes precedence over the configuration fragment applied via .scc/.cfg files.

2) In order to override the configuration item from defconfig (CONFIG_XXX) KERNEL_FEATURES needs to be used.

(In reply to comment #10)
> Let me rephrase:
> 
> 1) If a configuration item (CONFIG_XXX) is already in defconfig it takes
> precedence over the configuration fragment applied via .scc/.cfg files.
> 

That wasn't the design, but yes, due to ordering of an in-tree defconfig, that is the result. A SRC_URI based defconfig can be ordered a bit differently, but still has some ordering restrictions.

> 2) In order to override the configuration item from defconfig (CONFIG_XXX)
> KERNEL_FEATURES needs to be used.

Again, not by design, but if you are running into order issues (like you are), then yes, you can have the last word this way.

Bulk move as requesting during YP BB meeting.

Moving off old milestone per bug cleanup (to 6.2 M4).