Re: [OE-core] KCONF_AUDIT_LEVEL + kernel_configcheck
On Tue, 2015-06-16 at 09:48 -0400, Bruce Ashfield wrote: On 2015-06-16 04:06 AM, Patrick Ohly wrote: I cannot say how much noise it would create in practice, but at least I had one specific case where I was using a non-hardware configuration not supported by the kernel and would have appreciated a warning about that ;-} This is good feedback, and I am planning to expose more of the output, including some dependency information (since without giving hints on how to fix a warning .. more warnings are not all that helpful :) FWIW, my use case is the meta-security-smack layer, which is intended to be BSP independent, but needs to turn on certain kernel configuration options: https://github.com/01org/meta-intel-iot-security/tree/master/meta-security-smack/recipes-kernel/linux-yocto/linux-yocto This depends on a recent enough kernel or with the right patches back-ported, which is hard to test for in that layer, so warnings from the kernel configuration phase would be useful. Ideally, the warning should tell the user where the unsupported configuration option came from, because that's where the README is which explains the expectations of the layer regarding the underlying BSP. Speaking of that layer, I understand that not all kernels are called linux-yocto, and not all kernels support configuration fragments, so the linux-yocto_%.bbappend is not ideal, but the best I could come up with. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] KCONF_AUDIT_LEVEL + kernel_configcheck
On 2015-06-16 04:06 AM, Patrick Ohly wrote: On Mon, 2015-06-15 at 15:48 -0400, Bruce Ashfield wrote: On 2015-06-15 8:17 AM, Patrick Ohly wrote: Hello! In Fido and master, the following patch changed the default value of KCONF_AUDIT_LEVEL: $ git annotate origin/fido -- meta/classes/kernel-yocto.bbclass | grep KCONF_AUDIT_LEVEL ad4d5949(Bruce Ashfield 2015-02-18 16:15:35 -0500 308) config_check_visibility = int(d.getVar( KCONF_AUDIT_LEVEL, True ) or 0) $ git annotate origin/master -- meta/classes/kernel-yocto.bbclass | grep KCONF_AUDIT_LEVEL ad4d5949(Bruce Ashfield 2015-02-18 16:15:35 -0500 309) config_check_visibility = int(d.getVar( KCONF_AUDIT_LEVEL, True ) or 0) At least if I read it right, that wasn't the intention. The commit explicitly says that the default should be 1: The visibility of auditing is controlled by KCONF_AUDIT_LEVEL: 0: no reporting 1: report options that are specified, but not in the final config 2: report options that are not hardware related, but set by a BSP The default level is 1, with level 2 and above being for BSP development only. The line is correct, since we don't want it warning for non linux-yocto meta-data enabled kernels. The default is indeed 1, since I set it in the common include file. That was the default I was referring to in that change. Ah, I missed that other part of the patch. You are right of course. foobar.cfg is used (the CONFIG_SECURITY_SMACK part is used) but the CONFIG_FOOBAR part of course is not. Shouldn't this trigger the specified values did not make it into the kernel's final configuration? To keep the noise down, I'm only emitting partial audit information and the warnings only apply to options that are tagged as hardware, since that is also a synonym to 'required' in the configuration scheme. .. and no. That isn't common knowledge, since I've been slowly changing and making the audit information more visible, but don't want to flood too many warnings, or create an ABI that limits how we can change things. That explains it then. I don't remember how I learned about this kernel configuration check (might have seen the error message at some point) and came away with the impression that it applies to all configuration options. It was visible, then hidden, and then made visible again. So it has been a balancing act all along. I cannot say how much noise it would create in practice, but at least I had one specific case where I was using a non-hardware configuration not supported by the kernel and would have appreciated a warning about that ;-} This is good feedback, and I am planning to expose more of the output, including some dependency information (since without giving hints on how to fix a warning .. more warnings are not all that helpful :) Cheers, Bruce -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] KCONF_AUDIT_LEVEL + kernel_configcheck
On Mon, 2015-06-15 at 15:48 -0400, Bruce Ashfield wrote: On 2015-06-15 8:17 AM, Patrick Ohly wrote: Hello! In Fido and master, the following patch changed the default value of KCONF_AUDIT_LEVEL: $ git annotate origin/fido -- meta/classes/kernel-yocto.bbclass | grep KCONF_AUDIT_LEVEL ad4d5949(Bruce Ashfield 2015-02-18 16:15:35 -0500 308) config_check_visibility = int(d.getVar( KCONF_AUDIT_LEVEL, True ) or 0) $ git annotate origin/master -- meta/classes/kernel-yocto.bbclass | grep KCONF_AUDIT_LEVEL ad4d5949(Bruce Ashfield 2015-02-18 16:15:35 -0500 309) config_check_visibility = int(d.getVar( KCONF_AUDIT_LEVEL, True ) or 0) At least if I read it right, that wasn't the intention. The commit explicitly says that the default should be 1: The visibility of auditing is controlled by KCONF_AUDIT_LEVEL: 0: no reporting 1: report options that are specified, but not in the final config 2: report options that are not hardware related, but set by a BSP The default level is 1, with level 2 and above being for BSP development only. The line is correct, since we don't want it warning for non linux-yocto meta-data enabled kernels. The default is indeed 1, since I set it in the common include file. That was the default I was referring to in that change. Ah, I missed that other part of the patch. You are right of course. foobar.cfg is used (the CONFIG_SECURITY_SMACK part is used) but the CONFIG_FOOBAR part of course is not. Shouldn't this trigger the specified values did not make it into the kernel's final configuration? To keep the noise down, I'm only emitting partial audit information and the warnings only apply to options that are tagged as hardware, since that is also a synonym to 'required' in the configuration scheme. .. and no. That isn't common knowledge, since I've been slowly changing and making the audit information more visible, but don't want to flood too many warnings, or create an ABI that limits how we can change things. That explains it then. I don't remember how I learned about this kernel configuration check (might have seen the error message at some point) and came away with the impression that it applies to all configuration options. I cannot say how much noise it would create in practice, but at least I had one specific case where I was using a non-hardware configuration not supported by the kernel and would have appreciated a warning about that ;-} -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] KCONF_AUDIT_LEVEL + kernel_configcheck
Hello! In Fido and master, the following patch changed the default value of KCONF_AUDIT_LEVEL: $ git annotate origin/fido -- meta/classes/kernel-yocto.bbclass | grep KCONF_AUDIT_LEVEL ad4d5949(Bruce Ashfield 2015-02-18 16:15:35 -0500 308) config_check_visibility = int(d.getVar( KCONF_AUDIT_LEVEL, True ) or 0) $ git annotate origin/master -- meta/classes/kernel-yocto.bbclass | grep KCONF_AUDIT_LEVEL ad4d5949(Bruce Ashfield 2015-02-18 16:15:35 -0500 309) config_check_visibility = int(d.getVar( KCONF_AUDIT_LEVEL, True ) or 0) At least if I read it right, that wasn't the intention. The commit explicitly says that the default should be 1: The visibility of auditing is controlled by KCONF_AUDIT_LEVEL: 0: no reporting 1: report options that are specified, but not in the final config 2: report options that are not hardware related, but set by a BSP The default level is 1, with level 2 and above being for BSP development only. I found that while investigating why having an unsupported config option in one of my kernel fragments did not result in a warning. However, even with KCONF_AUDIT_LEVEL=2 in my local.conf, I still only get warnings about the BSP, but not my unsupported option. To reproduce, modify poky master as follows and build the default configuration: $ git diff --cached diff --git a/meta/recipes-kernel/linux/linux-yocto/foobar.cfg b/meta/recipes-kernel/linux/linux-yocto/foobar.cfg new file mode 100644 index 000..f40043a --- /dev/null +++ b/meta/recipes-kernel/linux/linux-yocto/foobar.cfg @@ -0,0 +1,2 @@ +CONFIG_FOOBAR=y +CONFIG_SECURITY_SMACK=y diff --git a/meta/recipes-kernel/linux/linux-yocto_3.19.bb b/meta/recipes-kernel/linux/linux-yocto_3.19.bb index 6218c02..d4b9437 100644 --- a/meta/recipes-kernel/linux/linux-yocto_3.19.bb +++ b/meta/recipes-kernel/linux/linux-yocto_3.19.bb @@ -38,3 +38,5 @@ KERNEL_FEATURES_append = ${KERNEL_EXTRA_FEATURES} KERNEL_FEATURES_append_qemux86= cfg/sound.scc cfg/paravirt_kvm.scc KERNEL_FEATURES_append_qemux86-64= cfg/sound.scc cfg/paravirt_kvm.scc KERNEL_FEATURES_append = ${@bb.utils.contains(TUNE_FEATURES, mx32, cfg/x32.scc, ,d)} + +SRC_URI += file://foobar.cfg ... $ bitbake -f -c kernel_configcheck linux-yocto Loading cache: 100% || ETA: 00:00:00 Loaded 1288 entries from dependency cache. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION= 1.27.1 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Debian-8.0 TARGET_SYS= i586-poky-linux MACHINE = qemux86 DISTRO= poky DISTRO_VERSION= 1.8+snapshot-20150615 TUNE_FEATURES = m32 i586 TARGET_FPU= meta meta-yocto meta-yocto-bsp= master:379a030702c985c6e69831173f765a47dfeb8841 NOTE: Preparing RunQueue NOTE: Tainting hash to force rebuild of task /work/poky/meta/recipes-kernel/linux/linux-yocto_3.19.bb, do_kernel_configcheck WARNING: /work/poky/meta/recipes-kernel/linux/linux-yocto_3.19.bb.do_configure is tainted from a forced run WARNING: /work/poky/meta/recipes-kernel/linux/linux-yocto_3.19.bb.do_kernel_configcheck is tainted from a forced run NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: [kernel config]: BSP specified non-hw configuration: CONFIG_BLOCK CONFIG_BT CONFIG_BT_6LOWPAN CONFIG_BT_BNEP CONFIG_BT_BNEP_MC_FILTER CONFIG_BT_BNEP_PROTO_FILTER CONFIG_BT_CMTP CONFIG_BT_HIDP CONFIG_BT_RFCOMM CONFIG_BT_RFCOMM_TTY CONFIG_CFG80211_WEXT CONFIG_CORDIC CONFIG_CRC8 CONFIG_EFIVAR_FS CONFIG_EFI_PARTITION CONFIG_NET CONFIG_NETDEVICES CONFIG_PARTITION_ADVANCED CONFIG_WEXT_CORE CONFIG_WEXT_PROC CONFIG_WIRELESS foobar.cfg is used (the CONFIG_SECURITY_SMACK part is used) but the CONFIG_FOOBAR part of course is not. Shouldn't this trigger the specified values did not make it into the kernel's final configuration? There is no mismatch.cfg, only a nonhw_report.cfg. This seems to point towards an error in the configure task, if I understand the kernel recipes correctly. Speaking of nonhw_report.cfg, are there plans to make the core BSPs clean enough to pass the check without warnings? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] KCONF_AUDIT_LEVEL + kernel_configcheck
On 2015-06-15 8:17 AM, Patrick Ohly wrote: Hello! In Fido and master, the following patch changed the default value of KCONF_AUDIT_LEVEL: $ git annotate origin/fido -- meta/classes/kernel-yocto.bbclass | grep KCONF_AUDIT_LEVEL ad4d5949(Bruce Ashfield 2015-02-18 16:15:35 -0500 308) config_check_visibility = int(d.getVar( KCONF_AUDIT_LEVEL, True ) or 0) $ git annotate origin/master -- meta/classes/kernel-yocto.bbclass | grep KCONF_AUDIT_LEVEL ad4d5949(Bruce Ashfield 2015-02-18 16:15:35 -0500 309) config_check_visibility = int(d.getVar( KCONF_AUDIT_LEVEL, True ) or 0) At least if I read it right, that wasn't the intention. The commit explicitly says that the default should be 1: The visibility of auditing is controlled by KCONF_AUDIT_LEVEL: 0: no reporting 1: report options that are specified, but not in the final config 2: report options that are not hardware related, but set by a BSP The default level is 1, with level 2 and above being for BSP development only. The line is correct, since we don't want it warning for non linux-yocto meta-data enabled kernels. The default is indeed 1, since I set it in the common include file. That was the default I was referring to in that change. I found that while investigating why having an unsupported config option in one of my kernel fragments did not result in a warning. However, even with KCONF_AUDIT_LEVEL=2 in my local.conf, I still only get warnings about the BSP, but not my unsupported option. To reproduce, modify poky master as follows and build the default configuration: $ git diff --cached diff --git a/meta/recipes-kernel/linux/linux-yocto/foobar.cfg b/meta/recipes-kernel/linux/linux-yocto/foobar.cfg new file mode 100644 index 000..f40043a --- /dev/null +++ b/meta/recipes-kernel/linux/linux-yocto/foobar.cfg @@ -0,0 +1,2 @@ +CONFIG_FOOBAR=y +CONFIG_SECURITY_SMACK=y diff --git a/meta/recipes-kernel/linux/linux-yocto_3.19.bb b/meta/recipes-kernel/linux/linux-yocto_3.19.bb index 6218c02..d4b9437 100644 --- a/meta/recipes-kernel/linux/linux-yocto_3.19.bb +++ b/meta/recipes-kernel/linux/linux-yocto_3.19.bb @@ -38,3 +38,5 @@ KERNEL_FEATURES_append = ${KERNEL_EXTRA_FEATURES} KERNEL_FEATURES_append_qemux86= cfg/sound.scc cfg/paravirt_kvm.scc KERNEL_FEATURES_append_qemux86-64= cfg/sound.scc cfg/paravirt_kvm.scc KERNEL_FEATURES_append = ${@bb.utils.contains(TUNE_FEATURES, mx32, cfg/x32.scc, ,d)} + +SRC_URI += file://foobar.cfg ... $ bitbake -f -c kernel_configcheck linux-yocto Loading cache: 100% || ETA: 00:00:00 Loaded 1288 entries from dependency cache. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION= 1.27.1 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Debian-8.0 TARGET_SYS= i586-poky-linux MACHINE = qemux86 DISTRO= poky DISTRO_VERSION= 1.8+snapshot-20150615 TUNE_FEATURES = m32 i586 TARGET_FPU= meta meta-yocto meta-yocto-bsp= master:379a030702c985c6e69831173f765a47dfeb8841 NOTE: Preparing RunQueue NOTE: Tainting hash to force rebuild of task /work/poky/meta/recipes-kernel/linux/linux-yocto_3.19.bb, do_kernel_configcheck WARNING: /work/poky/meta/recipes-kernel/linux/linux-yocto_3.19.bb.do_configure is tainted from a forced run WARNING: /work/poky/meta/recipes-kernel/linux/linux-yocto_3.19.bb.do_kernel_configcheck is tainted from a forced run NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: [kernel config]: BSP specified non-hw configuration: CONFIG_BLOCK CONFIG_BT CONFIG_BT_6LOWPAN CONFIG_BT_BNEP CONFIG_BT_BNEP_MC_FILTER CONFIG_BT_BNEP_PROTO_FILTER CONFIG_BT_CMTP CONFIG_BT_HIDP CONFIG_BT_RFCOMM CONFIG_BT_RFCOMM_TTY CONFIG_CFG80211_WEXT CONFIG_CORDIC CONFIG_CRC8 CONFIG_EFIVAR_FS CONFIG_EFI_PARTITION CONFIG_NET CONFIG_NETDEVICES CONFIG_PARTITION_ADVANCED CONFIG_WEXT_CORE CONFIG_WEXT_PROC CONFIG_WIRELESS foobar.cfg is used (the CONFIG_SECURITY_SMACK part is used) but the CONFIG_FOOBAR part of course is not. Shouldn't this trigger the specified values did not make it into the kernel's final configuration? To keep the noise down, I'm only emitting partial audit information and the warnings only apply to options that are tagged as hardware, since that is also a synonym to 'required' in the configuration scheme. .. and no. That isn't common knowledge, since I've been slowly changing and making the audit information more visible, but don't want to flood too many warnings, or create an ABI that limits how we can change things. There is no mismatch.cfg, only a nonhw_report.cfg. This seems to point towards an error in the configure task, if I understand the kernel