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
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
