kconfig usage in automatic kernel test

kconfig usage in automatic kernel test

[Cao jin]

Masahiro-san,

  I am writing some utility for internal kdump test with latest kernel,
my purpose is to test the new introduced kernel feature. For automatical
test, I see several config target could help, like olddefconfig, all*config.

But for my purpose, I don't find a good way. For example, olddefconfig
will let the now config item has default value, while some feature may
default to "N"; allyesconfig will slow the compilation notably.
But "all*config" has KCONFIG_ALLCONFIG help to customizing some config
item, that is a good utility, but seems it can't be used in olddefconfig.

All these things let me have 2 questions:

1. What would you suggest for my purpose?

2. allyesconfig, allmodconfig, randconfig seems useful for test kbuild,
but what's the purpose of allnoconfig, alldefconfig? In others words,
when people would need allnoconfig, alldefconfig?
-- 
Sincerely,
Cao jin

Re: kconfig usage in automatic kernel test

[Masahiro Yamada]

2018-07-06 17:49 GMT+09:00 Cao jin <caoj.fnst@cn.fujitsu.com>:
> Masahiro-san,
>
>   I am writing some utility for internal kdump test with latest kernel,
> my purpose is to test the new introduced kernel feature. For automatical
> test, I see several config target could help, like olddefconfig, all*config.
>
> But for my purpose, I don't find a good way. For example, olddefconfig
> will let the now config item has default value, while some feature may
> default to "N"; allyesconfig will slow the compilation notably.
> But "all*config" has KCONFIG_ALLCONFIG help to customizing some config
> item, that is a good utility, but seems it can't be used in olddefconfig.
>
> All these things let me have 2 questions:
>
> 1. What would you suggest for my purpose?


scripts/kconfig/merge_config.sh
can be used with any *config target.

If you want to tweak some symbols based on olddefconfig,
this could be the one you want.


> 2. allyesconfig, allmodconfig, randconfig seems useful for test kbuild,
> but what's the purpose of allnoconfig, alldefconfig? In others words,
> when people would need allnoconfig, alldefconfig?

I sometimes use allnoconfig for build testing.

When I want to test the whole build process quickly,
I disable as many drivers as possible to save time.


I do not use alldefconfig.
Anyway, it would not hurt to have it for completeness.


> --
> Sincerely,
> Cao jin
>
>



-- 
Best Regards
Masahiro Yamada

Re: kconfig usage in automatic kernel test

[Cao jin]

On 07/08/2018 10:15 AM, Masahiro Yamada wrote:
> 2018-07-06 17:49 GMT+09:00 Cao jin <caoj.fnst@cn.fujitsu.com>:
>> Masahiro-san,
>>
>>   I am writing some utility for internal kdump test with latest kernel,
>> my purpose is to test the new introduced kernel feature. For automatical
>> test, I see several config target could help, like olddefconfig, all*config.
>>
>> But for my purpose, I don't find a good way. For example, olddefconfig
>> will let the now config item has default value, while some feature may
>> default to "N"; allyesconfig will slow the compilation notably.
>> But "all*config" has KCONFIG_ALLCONFIG help to customizing some config
>> item, that is a good utility, but seems it can't be used in olddefconfig.
>>
>> All these things let me have 2 questions:
>>
>> 1. What would you suggest for my purpose?
> 
> 
> scripts/kconfig/merge_config.sh
> can be used with any *config target.
> 

I took a quick glance at the script, it seems a good method to me.
Thanks very much, Masahiro-san.

> If you want to tweak some symbols based on olddefconfig,
> this could be the one you want.
> 
> 
>> 2. allyesconfig, allmodconfig, randconfig seems useful for test kbuild,
>> but what's the purpose of allnoconfig, alldefconfig? In others words,
>> when people would need allnoconfig, alldefconfig?
> 
> I sometimes use allnoconfig for build testing.
> 
> When I want to test the whole build process quickly,
> I disable as many drivers as possible to save time.
> 
> 
> I do not use alldefconfig.
> Anyway, it would not hurt to have it for completeness.
> 

Thanks for clarifying.

-- 
Sincerely,
Cao jin