13928 2020-06-03 03:40:54 +0000 KERNEL_FEATURES_append vs. "classic" kernel meta data 2026-10-27 22:21:35 +0000 1 1 7 Build System, Metadata & Runtime OE-Core kernel 3.1 All Multiple ACCEPTED Medium normal 6.2 M4 1 pokylinux bruce.ashfield ccasciato randy.macleod richard.purdie tom.zanussi --- --- Don't know oldest_to_newest 87391 0 pokylinux 2020-06-03 03:40:54 +0000 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? 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? 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 [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 87393 1 bruce.ashfield 2020-06-03 06:16:40 +0000 (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 87433 2 pokylinux 2020-06-05 02:24:16 +0000 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 87436 3 bruce.ashfield 2020-06-05 13:53:23 +0000 Thanks for the config update. I'm starting some configuration runs on this now. 87437 4 bruce.ashfield 2020-06-05 20:25:56 +0000 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. 87438 5 pokylinux 2020-06-05 23:25:37 +0000 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. 87439 6 bruce.ashfield 2020-06-06 08:24:50 +0000 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. 87440 7 4689 bruce.ashfield 2020-06-06 11:27:49 +0000 Created attachment 4689 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. 87442 8 pokylinux 2020-06-08 01:19:22 +0000 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. 87443 9 bruce.ashfield 2020-06-08 05:56:32 +0000 (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. 87446 10 pokylinux 2020-06-08 08:40:21 +0000 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. 87448 11 bruce.ashfield 2020-06-08 08:54:17 +0000 (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. 101741 12 randy.macleod 2025-04-24 18:54:44 +0000 Bulk move as requesting during YP BB meeting. 107212 13 bruce.ashfield 2026-10-27 22:21:35 +0000 Moving off old milestone per bug cleanup (to 6.2 M4). 4689 2020-06-06 11:27:49 +0000 2020-06-06 11:27:49 +0000 patch under test 0001-kernel-yocto-ensure-that-defconfigs-are-processed-fi.patch text/plain 4466 bruce.ashfield RnJvbSAyMWNhMGYxNDUxZjU3OWQyOTNkM2RiNzdjNGM4NzI4NTU3YjdlMDJlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBCcnVjZSBBc2hmaWVsZCA8YnJ1Y2UuYXNoZmllbGRAZ21haWwu Y29tPgpEYXRlOiBTYXQsIDYgSnVuIDIwMjAgMTg6MTc6MjAgKzAwMDAKU3ViamVjdDogW1BBVENI XSBrZXJuZWwveW9jdG86IGVuc3VyZSB0aGF0IGRlZmNvbmZpZ3MgYXJlIHByb2Nlc3NlZCBmaXJz dAoKSXQgaXMgdW5jb21tb24gdGhhdCBhIEJTUCBkZWZpbml0aW9uIGFuZCBhIGRlZmNvbmZpZyBh cmUgdXNlZCBpbgphIHNpbmdsZSBjb25maWd1cmF0aW9uLiBUaGF0IGJlaW5nIHNhaWQsIGl0IGlz IGEgdmFsaWQgd2F5IHRvCm9yZ2FuaXplIGtlcm5lbCBjb25maWd1cmF0aW9uIG1ldGEgZGF0YS4K CldoZW4gYSBkZWZjb25maWcgaXMgdXNlZCwgZWl0aGVyIG9uIHRoZSBzcmNfdXJpIG9yIGZyb20g aW4KdGhlIGtlcm5lbCB0cmVlLCBpdCBpcyBub3JtYWxseSBleHBlY3RlZCB0aGF0IGl0IGlzIHRo ZSBiYXNlbGluZSwKd2l0aCBhbGwgb3B0aW9ucyBhcHBsaWVkIG9uIHRvcCBvZiBpdC4KCldpdGgg dGhpcyBjb21taXQsIHdlIGRldGVjdCBlaXRoZXIgdHlwZSBvZiBkZWZjb25maWcgYW5kIGVuc3Vy ZQp0aGF0IGl0IGlzIHVzZWQgZmlyc3QsIGZvbGxvd2VkIGJ5IHRoZSBmcmFnbWVudHMgaW4gdGhl aXIKcHJldmlvdXMgb3JkZXIuIFRoaXMgYWxsb3dzIGV4aXN0aW5nIGNvbmZpZ3VyYXRpb24gc3Rh Y2tzIHRvCnJlbWFpbiB0aGUgc2FtZSwgd2hpbGUgZW5zdXJpbmcgdGhhdCBhIGRlZmNvbmZpZyBj b21iaW5lZCBzdGFjawp3b3JrcyBhcyBleHBlY3RlZC4KClNpZ25lZC1vZmYtYnk6IEJydWNlIEFz aGZpZWxkIDxicnVjZS5hc2hmaWVsZEBnbWFpbC5jb20+Ci0tLQogbWV0YS9jbGFzc2VzL2tlcm5l bC15b2N0by5iYmNsYXNzIHwgMzMgKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLQogMSBm aWxlIGNoYW5nZWQsIDIxIGluc2VydGlvbnMoKyksIDEyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdp dCBhL21ldGEvY2xhc3Nlcy9rZXJuZWwteW9jdG8uYmJjbGFzcyBiL21ldGEvY2xhc3Nlcy9rZXJu ZWwteW9jdG8uYmJjbGFzcwppbmRleCA1YmM2MjcwNjZlLi40MWQ4NjIwZTY3IDEwMDY0NAotLS0g YS9tZXRhL2NsYXNzZXMva2VybmVsLXlvY3RvLmJiY2xhc3MKKysrIGIvbWV0YS9jbGFzc2VzL2tl cm5lbC15b2N0by5iYmNsYXNzCkBAIC0xMzEsNyArMTMxLDcgQEAgZG9fa2VybmVsX21ldGFkYXRh KCkgewogCQkJZWxzZQogCQkJCWNwIC1mICR7U30vYXJjaC8ke0FSQ0h9L2NvbmZpZ3MvJHtLQlVJ TERfREVGQ09ORklHfSAke1dPUktESVJ9L2RlZmNvbmZpZwogCQkJZmkKLQkJCXNjY3M9IiR7V09S S0RJUn0vZGVmY29uZmlnIgorCQkJaW5fdHJlZV9kZWZjb25maWc9IiR7V09SS0RJUn0vZGVmY29u ZmlnIgogCQllbHNlCiAJCQliYmZhdGFsICJBIEtCVUlMRF9ERUZDT05GSUcgJyR7S0JVSUxEX0RF RkNPTkZJR30nIHdhcyBzcGVjaWZpZWQsIGJ1dCBub3QgcHJlc2VudCBpbiB0aGUgc291cmNlIHRy ZWUiCiAJCWZpCkBAIC0xNTMsMTQgKzE1MywyNCBAQCBkb19rZXJuZWxfbWV0YWRhdGEoKSB7CiAJ cGF0Y2hlcz0iJHtAIiAiLmpvaW4oZmluZF9wYXRjaGVzKGQsJycpKX0iCiAJZmVhdF9kaXJzPSIk e0AiICIuam9pbihmaW5kX2tlcm5lbF9mZWF0dXJlX2RpcnMoZCkpfSIKIAotCSMgYSBxdWljayBj aGVjayB0byBtYWtlIHN1cmUgd2UgZG9uJ3QgaGF2ZSBkdXBsaWNhdGUgZGVmY29uZmlncwotCSMg SWYgdGhlcmUncyBhIGRlZmNvbmZpZyBpbiB0aGUgU1JDX1VSSSwgZGlkIHdlIGFsc28gaGF2ZSBv bmUgZnJvbQotCSMgdGhlIEtCVUlMRF9ERUZDT05GSUcgcHJvY2Vzc2luZyBhYm92ZSA/Ci0JaWYg WyAtbiAiJHNjY3MiIF07IHRoZW4KLQkgICAgIyB3ZSBkaWQgaGF2ZSBhIGRlZmNvbmZpZyBmcm9t IGFib3ZlLiByZW1vdmUgYW55IHRoYXQgbWlnaHQgYmUgaW4gdGhlIHNyY191cmkKLQkgICAgc2Nj c19mcm9tX3NyY191cmk9JChlY2hvICRzY2NzX2Zyb21fc3JjX3VyaSB8IGF3ayAneyBpZiAoJDAh PSJkZWZjb25maWciKSB7IHByaW50ICQwIH0gfScgUlM9JyAnKQorCSMgYSBxdWljayBjaGVjayB0 byBtYWtlIHN1cmUgd2UgZG9uJ3QgaGF2ZSBkdXBsaWNhdGUgZGVmY29uZmlncyBJZgorCSMgdGhl cmUncyBhIGRlZmNvbmZpZyBpbiB0aGUgU1JDX1VSSSwgZGlkIHdlIGFsc28gaGF2ZSBvbmUgZnJv bSB0aGUKKwkjIEtCVUlMRF9ERUZDT05GSUcgcHJvY2Vzc2luZyBhYm92ZSA/CisJc3JjX3VyaV9k ZWZjb25maWc9JChlY2hvICRzY2NzX2Zyb21fc3JjX3VyaSB8IGF3ayAneyBpZiAoJDA9PSJkZWZj b25maWciKSB7IHByaW50ICQwIH0gfScgUlM9JyAnKQorCSMgZHJvcCBhbmQgZGVmY29uZmlnJ3Mg ZnJvbSB0aGUgc3JjX3VyaSB2YXJpYWJsZSwgd2UgY2FwdHVyZWQgaXQganVzdCBhYm92ZSBoZXJl IGlmIGl0IGV4aXN0ZWQKKwlzY2NzX2Zyb21fc3JjX3VyaT0kKGVjaG8gJHNjY3NfZnJvbV9zcmNf dXJpIHwgYXdrICd7IGlmICgkMCE9ImRlZmNvbmZpZyIpIHsgcHJpbnQgJDAgfSB9JyBSUz0nICcp CisJaWYgWyAtbiAiJGluX3RyZWVfZGVmY29uZmlnIiBdOyB0aGVuCisJCXNjY3NfZGVmY29uZmln PSRpbl90cmVlX2RlZmNvbmZpZworCQlpZiBbIC1uICIkc3JjX3VyaV9kZWZjb25maWciIF07IHRo ZW4KKwkJCWJid2FybiAiW05PVEVdOiBkZWZjb25maWcgd2FzIHN1cHBsaWVkIGJvdGggdmlhIEtC VUlMRF9ERUZDT05GSUcgYW5kIFNSQ19VUkkuIERyb3BwaW5nIFNSQ19VUkkgZGVmY29uZmlnIgor CQlmaQorCWVsc2UKKwkJIyBpZiB3ZSBkaWRuJ3QgaGF2ZSBhbiBpbi10cmVlIG9uZSwgbWFrZSBv dXIgZGVmY29uZmlnIHRoZSBvbmUKKwkJIyBmcm9tIHRoZSBzcmNfdXJpLiBOb3RlOiB0aGVyZSBt YXkgbm90IGhhdmUgYmVlbiBvbmUgZnJvbSB0aGUKKwkJIyBzcmNfdXJpLCBzbyB0aGlzIGNhbiBi ZSBhbiBlbXB0eSB2YXJpYWJsZS4KKwkJc2Njc19kZWZjb25maWc9JHNyY191cmlfZGVmY29uZmln CiAJZmkKLQlzY2NzPSIkc2NjcyAkc2Njc19mcm9tX3NyY191cmkiCisJc2Njcz0iJHNjY3NfZnJv bV9zcmNfdXJpIgogCiAJIyBjaGVjayBmb3IgZmVhdHVyZSBkaXJlY3Rvcmllcy9yZXBvcy9icmFu Y2hlcyB0aGF0IHdlcmUgcGFydCBvZiB0aGUKIAkjIFNSQ19VUkkuIElmIHRoZXkgd2VyZSBzdXBw bGllZCwgd2UgY29udmVydCB0aGVtIGludG8gaW5jbHVkZSBkaXJlY3RpdmVzCkBAIC0xODcsMTEg KzE5NywxMCBAQCBkb19rZXJuZWxfbWV0YWRhdGEoKSB7CiAJIyBleHBhbmQga2VybmVsIGZlYXR1 cmVzIGludG8gdGhlaXIgZnVsbCBwYXRoIGVxdWl2YWxlbnRzCiAJYnNwX2RlZmluaXRpb249JChz cHAgJHtpbmNsdWRlc30gLS1maW5kIC1ES01BQ0hJTkU9JHtLTUFDSElORX0gLURLVFlQRT0ke0xJ TlVYX0tFUk5FTF9UWVBFfSkKIAlpZiBbIC16ICIkYnNwX2RlZmluaXRpb24iIF07IHRoZW4KLQkJ ZWNobyAiJHNjY3MiIHwgZ3JlcCAtcSBkZWZjb25maWcKLQkJaWYgWyAkPyAtbmUgMCBdOyB0aGVu CisJCWlmIFsgLXogIiRzY2NzX2RlZmNvbmZpZyIgXTsgdGhlbgogCQkJYmJmYXRhbF9sb2cgIkNv dWxkIG5vdCBsb2NhdGUgQlNQIGRlZmluaXRpb24gZm9yICR7S01BQ0hJTkV9LyR7TElOVVhfS0VS TkVMX1RZUEV9IGFuZCBubyBkZWZjb25maWcgd2FzIHByb3ZpZGVkIgogCQlmaQotCisJZWxzZQog CQkjIGlmIHRoZSBic3AgZGVmaW5pdGlvbiBoYXMgImRlZmluZSBLTUVUQV9FWFRFUk5BTF9CU1Ag dCIsCiAJCSMgdGhlbiB3ZSBuZWVkIHRvIHNldCBhIGZsYWcgdGhhdCB3aWxsIGluc3RydWN0IHRo ZSBuZXh0CiAJCSMgc3RlcHMgdG8gdXNlIHRoZSBCU1AgYXMgYm90aCBjb25maWd1cmF0aW9uIGFu ZCBwYXRjaGVzLgpAQCAtMjA2LDcgKzIxNSw3IEBAIGRvX2tlcm5lbF9tZXRhZGF0YSgpIHsKIAll bGVtZW50cz0iYGVjaG8gLW4gJHtic3BfZGVmaW5pdGlvbn0gJHtzY2NzfSAke3BhdGNoZXN9ICR7 S0VSTkVMX0ZFQVRVUkVTfWAiCiAJaWYgWyAtbiAiJHtlbGVtZW50c30iIF07IHRoZW4KIAkJZWNo byAiJHtic3BfZGVmaW5pdGlvbn0iID4gJHtTfS8ke21ldGFfZGlyfS9ic3BfZGVmaW5pdGlvbgot CQlzY2MgLS1mb3JjZSAtbyAke1N9LyR7bWV0YV9kaXJ9OmNmZyxtZXJnZSxtZXRhICR7aW5jbHVk ZXN9ICR7YnNwX2RlZmluaXRpb259ICR7c2Njc30gJHtwYXRjaGVzfSAke0tFUk5FTF9GRUFUVVJF U30KKwkJc2NjIC0tZm9yY2UgLW8gJHtTfS8ke21ldGFfZGlyfTpjZmcsbWVyZ2UsbWV0YSAke2lu Y2x1ZGVzfSAkc2Njc19kZWZjb25maWcgJGJzcF9kZWZpbml0aW9uICRzY2NzICRwYXRjaGVzICR7 S0VSTkVMX0ZFQVRVUkVTfQogCQlpZiBbICQ/IC1uZSAwIF07IHRoZW4KIAkJCWJiZmF0YWxfbG9n ICJDb3VsZCBub3QgZ2VuZXJhdGUgY29uZmlndXJhdGlvbiBxdWV1ZSBmb3IgJHtLTUFDSElORX0u IgogCQlmaQotLSAKMi4xOS4xCgo=