new way of writing defconfigs for freescale's powerpc platforms

Lijun Pan Lijun.Pan at freescale.com
Sat Apr 18 14:53:14 AEST 2015



> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, April 17, 2015 1:53 PM
> To: Pan Lijun-B44306
> Cc: Michael Ellerman; linuxppc-dev at ozlabs.org; Schmitt Richard-B43082
> Subject: Re: new way of writing defconfigs for freescale's powerpc platforms
> 
> On Fri, 2015-04-17 at 13:50 -0500, Pan Lijun-B44306 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Michael Ellerman [mailto:mpe at ellerman.id.au]
> > > Sent: Friday, April 17, 2015 1:19 AM
> > > To: Wood Scott-B07421
> > > Cc: Pan Lijun-B44306; linuxppc-dev at ozlabs.org; Schmitt
> > > Richard-B43082
> > > Subject: Re: new way of writing defconfigs for freescale's powerpc
> > > platforms
> > >
> > > On Thu, 2015-04-16 at 23:13 -0500, Scott Wood wrote:
> > > > On Fri, 2015-04-17 at 10:54 +1000, Michael Ellerman wrote:
> > > > > On Thu, 2015-04-09 at 21:52 +0000, Lijun Pan wrote:
> > > > > > 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?
> > > > >
> > > > > I don't like that the user has to manually run merge_config.sh.
> > > > >
> > > > > How does a user even know that it's an option?
> > > > >
> > > > > It also breaks scripts that auto build the kernel, which expect
> > > > > to be able to
> > > do:
> > > > >
> > > > >   $ make foo_defconfig
> > > > >   $ make
> > > > >
> > > > > Scripts like mine for example :)
> > > > >
> > > > >   http://kisskb.ellerman.id.au/kisskb/head/8734/
> > > > >
> > > > > What I'd be happy with is something that does merge_config under
> > > > > the covers. So a user still runs 'make fsl_plat_foo_defconfig',
> > > > > but under the covers it does a merge config.
> > > > >
> > > > > kvmconfig and tinyconfig are implemented that way already, so
> > > > > with a bit more work hopefully you can do that for arch configs also.
> > > >
> > > > kvmconfig and tinyconfig are still separate user-visible steps to
> > > > be applied after running a base defconfig.
> > >
> > > Not as of recently:
> > >
> > >
> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/comm
> > > it/scripts/kc
> > > onfig/Makefile?id=63a91033d52e64a22e571fe84924c0b7f21c280d
> > >
> >
> > Above patch is very generic.
> > With this patch, we don't even need to modify arch/powerpc/Makefile.
> > We can just add fragments (like smp.config, kvm_guest.config, etc)
> > under arch/powerpc/configs/ or add platform independent config under
> > kernel/configs/
> >
> > example might be:
> > make mpc85xx_defconfig
> > make smp.config
> > make kvm_guest.config
> 
> The point is that the user should not have to do that.  They can if they want,
> but there should still be traditional named configs, which would just work
> differently under the hood.
> 
> -Scott
> 

Have just sent out a patch considering the previous discussion.
http://patchwork.ozlabs.org/patch/462249/
[PATCH] powerpc/defconfig: new way of writing defconfig



More information about the Linuxppc-dev mailing list