Re: KCONF_AUDIT_LEVEL + kernel_configcheck

[Patrick Ohly <patrick.ohly@intel.com>]

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.