Re: KCONF_AUDIT_LEVEL + kernel_configcheck

[Bruce Ashfield <bruce.ashfield@windriver.com>]

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

>