Re: Kernel features

[Ilya Dmitrichenko <errordeveloper@gmail.com>]

Hi Bruce,

On 7 September 2014 15:17, Bruce Ashfield <bruce.ashfield@windriver.com> wrote:
> On 2014-09-07, 4:51 AM, Ilya Dmitrichenko wrote:
>>
>> Today I have spent quite a while trying to figure how KERNEL_FEATURES
>> works and why some of the things I pass in my configuration fragment
>> are not getting enabled.
>>
>> It turned out that some of the options no longer existed and some had
>> been renamed.
>
>
> Do you have an example ? We try and not rename or remove public facing
> configuration fragments, and hide the changing CONFIG_* values behind
> the fragment names.

Here is what I was doing first:

CONFIG_SND_OMAP_SOC=n
CONFIG_SND_OMAP_SOC_MCBSP=n
CONFIG_SND_OMAP_SOC_OMAP_TWL4030=n
CONFIG_SND_SOC_TWL4030=n
CONFIG_SND_AM335X_SOC_EVM=m
CONFIG_SND_AM33XX_SOC=m
CONFIG_SND_DAVINCI_SOC_MCASP=m
CONFIG_SND_HRTIMER=m

This is resulted in disabled options propagating as expected and
CONFIG_SND_HRTIMER worked as well.

The rest, however didn't.

It turned out that basically CONFIG_SND_AM335X_SOC_EVM is misspelled
and should be called CONFIG_SND_AM33XX_SOC_EVM. I think there must be
a way to verify whether this existed or not.

It then also turned out that CONFIG_SND_AM335X_SOC_EVM depends on
CONFIG_SND_DAVINCI_SOC, and I had to enable that one and ensure it
comes first.

This is a working set:

CONFIG_SND_OMAP_SOC=m
CONFIG_SND_OMAP_SOC_MCBSP=m
CONFIG_SND_OMAP_SOC_OMAP_TWL4030=m
CONFIG_SND_SOC_TWL4030=m
CONFIG_SND_DAVINCI_SOC=m
CONFIG_SND_AM33XX_SOC_EVM=m
CONFIG_SND_DAVINCI_SOC_MCASP=m
CONFIG_SND_HRTIMER=m


>> The question is really why would this not get detected by
>> kernel_configcheck or any other step?
>>
>> I'm guessing this might be the case of how kconfig works, perhaps...
>> So I wonder whether anyone have looked into how we could actually get
>> the feature dependency graph from kconfig to bitbake or at least some
>> sort of helper tool? Perhaps parsing kconfig manifests in Python would
>> be a starting point...
>
>
> There have been many efforts are changing, writing and processing
> Kconfig constructs in other languages .. they all end up being
> pretty much a re-implementation of Kconfig, and hence a big effort
> that needs to be continuously maintained over time .. also a big
> effort.

I basically think that we could do something better then blindly
throwing a set of options without verifying it.

The reason I mentioned Python was that I though of sharing Kconfig's
dependency graph with bitbake and thereby detecting errors like the
above.

As a user, this is what I'd love to see:

Error: The Kconfig option CONFIG_SND_AM335X_SOC_EVM that you have
specified doesn't exist. (Did you mean CONFIG_SND_AM33XX_SOC_EVM?)

Error: The Kconfig option CONFIG_SND_AM33XX_SOC that you have
specified doesn't exist. (Nothing similar exists)

Warning: The Kconfig option CONFIG_SND_DAVINCI_SOC_MCASP that you have
specified depends on CONFIG_SND_DAVINCI_SOC. I will enable
CONFIG_SND_DAVINCI_SOC as a module for you.

Hope this makes more sense.

Cheers,
-- 
Ilya