new way of writing defconfigs for freescale's powerpc platforms

Lijun Pan Lijun.Pan at freescale.com
Fri Apr 10 07:52:23 AEST 2015


Hi Maintainers,

We have a proposal for writing the defconfigs for freescale's powperpc platforms in a new way.
Can you take a look and provide some feedback?

You know currently we have mpc85xx_defconfig, corenet32_defconfig, bsc913x_defconfig, *fman*_defconfig, etc.
We are going to extract some common parts from the existing defconfigs, and name it, say, fsl_basic_defconfig.
Then, we could create some defconfigs targeting specific features or specific platforms.
Say, features specific: kvm_defconfig, fman_defconfig, etc.
Platforms specific: p1_defconfig, p2_defcongfig, p4_defconfig, t1_defconfig, t2_defconfig, t2_defconfig, b4_defconfig, etc
When we want to make a kernel image for p1 platform,
Using the following steps:

make ./scripts/kconfig/merge_config.sh arch/powerpc/configs/fsl_basic_config p1_defconfig
make

What do you think of this new approach?
Will you accept this approach?

Here is a brief quote of the reasons why we take this approach.
"we've had complaints in the past that some feature X  is available on one platform but not another. 
Why.  And our answer has been, it's arbitrary. 
Some platform config files define it, and some platform config files don't.  
That's because when someone adds a feature, they don't update all relevant defconfigs.

Sometimes config files that should be very similar, are in fact very different. 
take for example corenet32_smp_defconfig and corenet64_smp_defconfig.  
There are differences in mtd settings, and others when the only difference should be very close to just PPC64.

So the hope was to create some kind of layered architecture.  
Have a basic defconfig, then maybe have a fragment for 64 bit, 
then fragments for particular platform differences, then a fragment for KVM, 
and a fragment for ASF and so on."

Thanks
Lijun


More information about the Linuxppc-dev mailing list