From: Scott Wood <scottwood@freescale.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Lijun Pan <Lijun.Pan@freescale.com>,
Richard Schmitt <richard.schmitt@freescale.com>,
"linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>
Subject: Re: new way of writing defconfigs for freescale's powerpc platforms
Date: Thu, 16 Apr 2015 23:13:20 -0500 [thread overview]
Message-ID: <1429244000.32545.51.camel@freescale.com> (raw)
In-Reply-To: <1429232060.22546.7.camel@ellerman.id.au>
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.
For breaking a platform defconfig into components, we could do something
like this in arch/powerpc/Makefile:
# Can't call mergeconfig directly as it isn't defined at this point
define domerge
@$(MAKE) -f $(srctree)/scripts/kconfig/Makefile $(1).config
endef
corenet64_smp_defconfig: corenet64_basic_defconfig
$(call domerge,smp)
$(call domerge,altivec)
$(call domerge,corenet_drivers)
$(call domerge,embedded_misc) # filesystems etc
And this in scripts/kconfig/Makefile:
%.config:
$(call mergeconfig,$*)
One issue with this is that we'd lose the ability to use savedefconfig
(at least without manual manipulation of the results) to maintain the
defconfigs/fragments.
-Scott
next prev parent reply other threads:[~2015-04-17 4:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-09 21:52 new way of writing defconfigs for freescale's powerpc platforms Lijun Pan
2015-04-09 22:31 ` Scott Wood
2015-04-16 4:44 ` Bob Cochran
2015-04-16 13:20 ` Bob Cochran
2015-04-16 13:37 ` Richard Schmitt
2015-04-16 18:39 ` Scott Wood
2015-04-16 17:04 ` Lijun Pan
2015-04-17 0:54 ` Michael Ellerman
2015-04-17 4:13 ` Scott Wood [this message]
2015-04-17 6:18 ` Michael Ellerman
2015-04-17 18:50 ` Lijun Pan
2015-04-17 18:52 ` Scott Wood
2015-04-18 4:53 ` Lijun Pan
2015-04-18 13:46 ` Timur Tabi
2015-04-20 20:31 ` Scott Wood
2015-04-21 2:02 ` Timur Tabi
2015-04-21 2:09 ` Scott Wood
2015-04-21 3:42 ` Timur Tabi
2015-04-21 5:01 ` Scott Wood
2015-04-21 13:25 ` Timur Tabi
2015-04-21 17:55 ` Scott Wood
2015-04-21 18:11 ` Timur Tabi
2015-04-21 18:12 ` Scott Wood
2015-04-21 3:27 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1429244000.32545.51.camel@freescale.com \
--to=scottwood@freescale.com \
--cc=Lijun.Pan@freescale.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=richard.schmitt@freescale.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.