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
