On 02/13/2018 05:00 AM, Mircea Gliga wrote:
Hi
Short story: I'm using rocko and have a recipe for Linux kernel 4.14.14
based on linux-yocto.inc, some kernel fragments end up in the resulting
.config, other don't, if regenerate fragments using menuconfig +
diffconfig seems ok.
Long story:
In my recipe linux-stable_4.14.bb I have an inc file:
[...]
require linux-stable.inc
[...]
linux-stable.inc :
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
[...]
SRC_URI += "file://defconfig \
file://kernel_fragments/netfilter.cfg \
file://kernel_fragments/overlayfs.cfg \
file://kernel_fragments/verity.cfg \
file://kernel_fragments/squashfs.cfg \
file://kernel_fragments/modem.cfg \
file://kernel_fragments/led_oneshot.cfg \
file://kernel_fragments/ipsec.cfg \
file://kernel_fragments/netbridge.cfg \
file://kernel_fragments/atmel_hw_sha.cfg \
I have a set of kernel fragments. During `bitbake linux-stable -c
kernel_configme -f` some of them end up in the .config file while others
don't:
led_oneshot.cfg and overlayfs.cfg are not applied in the resulting
.config while verity.cfg is applied.
They are all generated using menuconfig to config the kernel, then
diffconfig to generate the fragment.
$ cat led_oneshot.cfg
CONFIG_LEDS_TRIGGER_ONESHOT=y
$ cat verity.cfg
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BCACHE is not set
CONFIG_BLK_DEV_DM_BUILTIN=y
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_MQ_DEFAULT is not set
# CONFIG_DM_DEBUG is not set
CONFIG_DM_BUFIO=y
# CONFIG_DM_DEBUG_BLOCK_MANAGER_LOCKING is not set
CONFIG_DM_CRYPT=y
# CONFIG_DM_SNAPSHOT is not set
# CONFIG_DM_THIN_PROVISIONING is not set
# CONFIG_DM_CACHE is not set
# CONFIG_DM_ERA is not set
# CONFIG_DM_MIRROR is not set
# CONFIG_DM_RAID is not set
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
# CONFIG_DM_UEVENT is not set
# CONFIG_DM_FLAKEY is not set
CONFIG_DM_VERITY=y
# CONFIG_DM_VERITY_FEC is not set
# CONFIG_DM_SWITCH is not set
# CONFIG_DM_LOG_WRITES is not set
# CONFIG_DM_INTEGRITY is not set
$ cat overlayfs.cfg
CONFIG_OVERLAY_FS=y
# CONFIG_OVERLAY_FS_REDIRECT_DIR is not set
# CONFIG_OVERLAY_FS_INDEX is not set
$
Now, if I go in menuconfig I can see that CONFIG_OVERLAY_FS is indeed
not enabled, I then enable it and generate a new fragment,
fragmentOverlay.cfg:
$ cat fragmentOverlay.cfg
CONFIG_OVERLAY_FS=y
# CONFIG_OVERLAY_FS_REDIRECT_DIR is not set
# CONFIG_OVERLAY_FS_INDEX is not set
$ md5sum *verlay*
14f88a8b2dcb256c38f6362161045831 fragmentOverlay.cfg
14f88a8b2dcb256c38f6362161045831 overlayfs.cfg
The new fragment is identical to the overlayfs.cfg (which is not applied).
I let both files in the SCR_URI:
SRC_URI += "[...]
file://kernel_fragments/overlayfs.cfg \
file://kernel_fragments/fragmentOverlay.cfg \
[...]"
And now after `bitbake linux-stable -c kernel_configme -f` the resulting
.config has the overlay_fs enabled:
$ cat .config | grep OVERLAY_FS
CONFIG_OVERLAY_FS=y
# CONFIG_OVERLAY_FS_REDIRECT_DIR is not set
# CONFIG_OVERLAY_FS_INDEX is not set
$ cat .config |grep CONFIG_LEDS_TRIGGER_ONESHOT
# CONFIG_LEDS_TRIGGER_ONESHOT is not set
Same contents in the fragments, one is applied while the other is not ...
There's absolutely no conditional processing around fragments, they are
always applied to the kernel. When a symbol doesn't make it into the
final .config, it is due to dependencies or a further fragment disabling
something.
In the LEDS_TRIGGER_ONESHOT example, which one of your fragments
or base configs is turning on LEDS_TRIGGERS and LEDS_CLASS ? That's
as far as I looked into the dependency tree, but there could be
more.
When a SRC_URI contains a 'defconfig', it triggers a very specific
base setup of the kernel options since it assumes that it is a
full defconfig. This means that merge_config is called with -n, which
translates to "allnoconfig" as the base setup. Hence, if you are
counting on something being set to the default, that step will turn
it off if you are using a 'defconfig'.
You can still use the defconfig and have a different mode for that
baseline setup. Just set KCONFIG_MODE="alldefconfig" in your bbappend
and that will be used instead.
Note: the semantics of this will change slightly when I send an
upcoming series that shuffles things around, but it won't change the
flow that I'm describing above.
If that tweak doesn't help, can I get access to you config to run some
tests here ? I have some more patches that have improved audit steps
that should highlight the symbols and their dependencies, but I need
to test/clean them up more.
Cheers,
Bruce
Do you have any hints ?
Thanks and regards!
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
