* KCONF_AUDIT_LEVEL + kernel_configcheck
@ 2015-06-15 12:17 Patrick Ohly
2015-06-15 19:48 ` Bruce Ashfield
0 siblings, 1 reply; 5+ messages in thread
From: Patrick Ohly @ 2015-06-15 12:17 UTC (permalink / raw)
To: OpenEmbedded, Bruce Ashfield
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 0000000..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.
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: KCONF_AUDIT_LEVEL + kernel_configcheck
2015-06-15 12:17 KCONF_AUDIT_LEVEL + kernel_configcheck Patrick Ohly
@ 2015-06-15 19:48 ` Bruce Ashfield
2015-06-16 8:06 ` Patrick Ohly
0 siblings, 1 reply; 5+ messages in thread
From: Bruce Ashfield @ 2015-06-15 19:48 UTC (permalink / raw)
To: Patrick Ohly, OpenEmbedded
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 0000000..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
> recipes correctly.
See above. No mismatch for options that aren't tagged as h/w.
>
> Speaking of nonhw_report.cfg, are there plans to make the core BSPs
> clean enough to pass the check without warnings?
They pass for h/w options cleanly in 1.7 and 1.8, we get bugs and clean
up any visible warnings.
For 1.9, there's a whole slate of kernel audit, kernel configuration and
other changes that will do more cleaning.
Bruce
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: KCONF_AUDIT_LEVEL + kernel_configcheck
2015-06-15 19:48 ` Bruce Ashfield
@ 2015-06-16 8:06 ` Patrick Ohly
2015-06-16 13:48 ` Bruce Ashfield
0 siblings, 1 reply; 5+ messages in thread
From: Patrick Ohly @ 2015-06-16 8:06 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: OpenEmbedded
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: KCONF_AUDIT_LEVEL + kernel_configcheck
2015-06-16 8:06 ` Patrick Ohly
@ 2015-06-16 13:48 ` Bruce Ashfield
2015-06-18 9:51 ` Patrick Ohly
0 siblings, 1 reply; 5+ messages in thread
From: Bruce Ashfield @ 2015-06-16 13:48 UTC (permalink / raw)
To: Patrick Ohly; +Cc: OpenEmbedded
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
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: KCONF_AUDIT_LEVEL + kernel_configcheck
2015-06-16 13:48 ` Bruce Ashfield
@ 2015-06-18 9:51 ` Patrick Ohly
0 siblings, 0 replies; 5+ messages in thread
From: Patrick Ohly @ 2015-06-18 9:51 UTC (permalink / raw)
To: Bruce Ashfield; +Cc: OpenEmbedded
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-06-18 9:51 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-15 12:17 KCONF_AUDIT_LEVEL + kernel_configcheck Patrick Ohly
2015-06-15 19:48 ` Bruce Ashfield
2015-06-16 8:06 ` Patrick Ohly
2015-06-16 13:48 ` Bruce Ashfield
2015-06-18 9:51 ` Patrick Ohly
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.