Re: new way of writing defconfigs for freescale's powerpc platforms
On 04/21/2015 12:55 PM, Scott Wood wrote: > >Ok, then define a new Kconfig option that merge_config.sh will look for. > So in p1_defconfig, there will be this line: > >CONFIG_OTHER_DEFCONFIGS=fsl_basic_config If you want to do that go ahead. In the meantime we'll use the mechanism that already exists. Dude, you are not making any sense. If there is a mechanism that already exists, then what are we talking about? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Tue, 2015-04-21 at 13:11 -0500, Timur Tabi wrote: > On 04/21/2015 12:55 PM, Scott Wood wrote: > >> > > >> >Ok, then define a new Kconfig option that merge_config.sh will look for. > >> > So in p1_defconfig, there will be this line: > >> > > >> >CONFIG_OTHER_DEFCONFIGS=fsl_basic_config > > If you want to do that go ahead. In the meantime we'll use the > > mechanism that already exists. > > Dude, you are not making any sense. If there is a mechanism that > already exists, then what are we talking about? Using it! -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Tue, 2015-04-21 at 08:25 -0500, Timur Tabi wrote: > Scott Wood wrote: > > We want single-name config targets to still work from the user's > > perspective, but we want to reduce the (often imperfect) duplication > > under the hood. > > Ok, then define a new Kconfig option that merge_config.sh will look for. > So in p1_defconfig, there will be this line: > > CONFIG_OTHER_DEFCONFIGS=fsl_basic_config If you want to do that go ahead. In the meantime we'll use the mechanism that already exists. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
Scott Wood wrote: We want single-name config targets to still work from the user's perspective, but we want to reduce the (often imperfect) duplication under the hood. Ok, then define a new Kconfig option that merge_config.sh will look for. So in p1_defconfig, there will be this line: CONFIG_OTHER_DEFCONFIGS=fsl_basic_config -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Mon, 2015-04-20 at 22:42 -0500, Timur Tabi wrote: > Scott Wood wrote: > >> > > >> >Why do you need a powerpc-specific way to use merge_config.sh? Other > >> >architectures have the same problem with defconfigs. > > > What are you perceiving as "powerpc-specific" about what we're > > proposing? > > Well, there's the subject of this thread, which is "new way of writing > defconfigs for freescale's powerpc platforms". > > > Are you complaining about the actual content of which > > fragments to use to produce which defconfigs going in arch/powerpc? > > No, I'm just trying to figure out what's powerpc-specific about Lijun's > proposal. The set of defconfigs that we're talking about refactoring to use this mechanism. > >> >Besides, wouldn't it make more sense to define a new defconfig type, > >> >like p1_defconfig.merge, and if you do "make p1_defconfig.merge" it > >> >knows to call merge_config.sh? > > > That's already there. "make .config". > > Ok, so I'm definitely confused now. I have no idea what's actually > being proposed, since apparently the ability to have merge configs > already exists. The proposal is that we make use of that mechanism. > Wouldn't it just be simpler to pass multiple defconfigs to 'make', and > then 'make' will know to call merge_config.sh on them? So instead of > > make ./scripts/kconfig/merge_config.sh > arch/powerpc/configs/fsl_basic_config p1_defconfig > make > > we can just do > > make fsl_basic_config p1_defconfig > make We want single-name config targets to still work from the user's perspective, but we want to reduce the (often imperfect) duplication under the hood. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
Scott Wood wrote: > >Why do you need a powerpc-specific way to use merge_config.sh? Other >architectures have the same problem with defconfigs. What are you perceiving as "powerpc-specific" about what we're proposing? Well, there's the subject of this thread, which is "new way of writing defconfigs for freescale's powerpc platforms". > Are you complaining about the actual content of which fragments to use to produce which defconfigs going in arch/powerpc? No, I'm just trying to figure out what's powerpc-specific about Lijun's proposal. >Besides, wouldn't it make more sense to define a new defconfig type, >like p1_defconfig.merge, and if you do "make p1_defconfig.merge" it >knows to call merge_config.sh? That's already there. "make .config". Ok, so I'm definitely confused now. I have no idea what's actually being proposed, since apparently the ability to have merge configs already exists. Wouldn't it just be simpler to pass multiple defconfigs to 'make', and then 'make' will know to call merge_config.sh on them? So instead of make ./scripts/kconfig/merge_config.sh arch/powerpc/configs/fsl_basic_config p1_defconfig make we can just do make fsl_basic_config p1_defconfig make -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Mon, 2015-04-20 at 21:02 -0500, Timur Tabi wrote: > On Mon, Apr 20, 2015 at 3:31 PM, Scott Wood wrote: > > > > > > The ability to merge configs is already there. We're just talking about > > using that functionality. > > Why do you need a powerpc-specific way to use merge_config.sh? Other > architectures have the same problem with defconfigs. Because no one has written a generic way to do it, are you volunteering? > Besides, wouldn't it make more sense to define a new defconfig type, > like p1_defconfig.merge, and if you do "make p1_defconfig.merge" it > knows to call merge_config.sh? No, we want the existing defconfig names to continue working. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Mon, 2015-04-20 at 21:02 -0500, Timur Tabi wrote: > On Mon, Apr 20, 2015 at 3:31 PM, Scott Wood wrote: > > > > > > The ability to merge configs is already there. We're just talking about > > using that functionality. > > Why do you need a powerpc-specific way to use merge_config.sh? Other > architectures have the same problem with defconfigs. What are you perceiving as "powerpc-specific" about what we're proposing? Are you complaining about the actual content of which fragments to use to produce which defconfigs going in arch/powerpc? > Besides, wouldn't it make more sense to define a new defconfig type, > like p1_defconfig.merge, and if you do "make p1_defconfig.merge" it > knows to call merge_config.sh? That's already there. "make .config". -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Mon, Apr 20, 2015 at 3:31 PM, Scott Wood wrote: > > > The ability to merge configs is already there. We're just talking about > using that functionality. Why do you need a powerpc-specific way to use merge_config.sh? Other architectures have the same problem with defconfigs. Besides, wouldn't it make more sense to define a new defconfig type, like p1_defconfig.merge, and if you do "make p1_defconfig.merge" it knows to call merge_config.sh? -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Sat, 2015-04-18 at 08:46 -0500, Timur Tabi wrote: > On Fri, Apr 17, 2015 at 11:53 PM, Lijun Pan wrote: > > > Have just sent out a patch considering the previous discussion. > > http://patchwork.ozlabs.org/patch/462249/ > > [PATCH] powerpc/defconfig: new way of writing defconfig > > The ability to merge defconfigs is a feature that's been requested by > many people for a long time. Any solution should definitely NOT be > PowerPC-only. The ability to merge configs is already there. We're just talking about using that functionality. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Fri, Apr 17, 2015 at 11:53 PM, Lijun Pan wrote: > Have just sent out a patch considering the previous discussion. > http://patchwork.ozlabs.org/patch/462249/ > [PATCH] powerpc/defconfig: new way of writing defconfig The ability to merge defconfigs is a feature that's been requested by many people for a long time. Any solution should definitely NOT be PowerPC-only. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: new way of writing defconfigs for freescale's powerpc platforms
> -Original Message- > From: Bob Cochran [mailto:p...@mindchasers.com] > Sent: Thursday, April 16, 2015 8:21 AM > To: Wood Scott-B07421; Pan Lijun-B44306 > Cc: linuxppc-...@ozlabs.org; Schmitt Richard-B43082 > Subject: Re: new way of writing defconfigs for freescale's powerpc platforms > > On 04/16/2015 12:44 AM, Bob Cochran wrote: > > On 04/09/2015 06:31 PM, Scott Wood wrote: > >> On Thu, 2015-04-09 at 16:52 -0500, Pan Lijun-B44306 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? > >>> Will you accept this approach? > >> > >> I'm OK with a merge_config approach. > >> > >> I'm not OK with having separate builds for p1/p2/p4/t1/t2/b4. > >> > >> -Scott > > > > > > As you probably know, Freescale makes use of the Yocto Project build > > system for its SDK and submits patches to the SDK at a public > > meta-fsl-ppc repo at > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/ > > > > I have seen some kernel related patches in the past come across the > > Yocto Project site that made use of the Yocto Project kernel tools, > > which includes a process for maintaining kernel configuration fragments. > > > Here is a link to a patch from a Freescale developer introducing Yocto kernel > tool support (description files & configuration fragments) to the meta-fsl-ppc > repo (FSL QorIQ SDK on Yocto). > > https://lists.yoctoproject.org/pipermail/meta-freescale/2014- > October/010890.html > > Yes, we do also intend to support this in Yocto and that the fragments will be applied during the build process as part of Yocto recipes and Kernel Features. The first step in doing this is creating the fragments and providing a means to create the platform defconfigs without Yocto. > > > It sounds like the requirements you have could be met with Yocto's > > existing process. > > > > I was hoping to see Freescale continue to move in the direction of > > using the Yocto kernel tools rather than roll its own solution. There are a number of activities we are doing that will bring us more in the direction of the Yocto kernel tools. But again, Yocto is one way, not the only way. So we intend to support a Makefile approach to building configs (similar to Intel) as well as a Yocto approach to building configs. > > > > The Yocto kernel tools make use of description files (*.scc) and > > configuration fragments (*.cfg). > > > > Here is a link to the latest stable Yocto kernel development manual: > > http://www.yoctoproject.org/docs/1.7.1/kernel-dev/kernel-dev.html > > > > Bob > > > > Rich > > > > > > > >> > >> > >> ___ > >> Linuxppc-dev mailing list > >> Linuxppc-dev@lists.ozlabs.org > >> https://lists.ozlabs.org/listinfo/linuxppc-dev > >> > > > > ___ > > Linuxppc-dev mailing list > > Linuxppc-dev@lists.ozlabs.org > > https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: new way of writing defconfigs for freescale's powerpc platforms
> -Original Message- > From: Wood Scott-B07421 > Sent: Friday, April 17, 2015 1:53 PM > To: Pan Lijun-B44306 > Cc: Michael Ellerman; linuxppc-...@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:m...@ellerman.id.au] > > > Sent: Friday, April 17, 2015 1:19 AM > > > To: Wood Scott-B07421 > > > Cc: Pan Lijun-B44306; linuxppc-...@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 +, 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
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:m...@ellerman.id.au] > > Sent: Friday, April 17, 2015 1:19 AM > > To: Wood Scott-B07421 > > Cc: Pan Lijun-B44306; linuxppc-...@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 +, 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/commit/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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: new way of writing defconfigs for freescale's powerpc platforms
> -Original Message- > From: Michael Ellerman [mailto:m...@ellerman.id.au] > Sent: Friday, April 17, 2015 1:19 AM > To: Wood Scott-B07421 > Cc: Pan Lijun-B44306; linuxppc-...@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 +, 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/commit/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 > > Which pretty much does what you describe below I think. > > > 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. > > That's probably OK, it's only maintainers who need to do that. > > cheers > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
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 +, 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/commit/scripts/kconfig/Makefile?id=63a91033d52e64a22e571fe84924c0b7f21c280d Which pretty much does what you describe below I think. > 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. That's probably OK, it's only maintainers who need to do that. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Fri, 2015-04-17 at 10:54 +1000, Michael Ellerman wrote: > On Thu, 2015-04-09 at 21:52 +, 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Thu, 2015-04-09 at 21:52 +, 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. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On Thu, 2015-04-16 at 00:44 -0400, Bob Cochran wrote: > As you probably know, Freescale makes use of the Yocto Project build > system for its SDK and submits patches to the SDK at a public > meta-fsl-ppc repo at http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/ > > I have seen some kernel related patches in the past come across the > Yocto Project site that made use of the Yocto Project kernel tools, > which includes a process for maintaining kernel configuration fragments. > It sounds like the requirements you have could be met with Yocto's > existing process. > > I was hoping to see Freescale continue to move in the direction of using > the Yocto kernel tools rather than roll its own solution. > > The Yocto kernel tools make use of description files (*.scc) and > configuration fragments (*.cfg). We do use Yocto for our SDK, but there's always going to be a need to be able to build kernels outside of Yocto. The kernel should be self-contained regarding its own configuration. merge_config.sh isn't "rolling our own solution". It's a standard kernel tool. x86 already has a couple config fragments defined. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: new way of writing defconfigs for freescale's powerpc platforms
> -Original Message- > From: Wood Scott-B07421 > Sent: Thursday, April 09, 2015 5:31 PM > To: Pan Lijun-B44306 > Cc: linuxppc-...@ozlabs.org; Schmitt Richard-B43082 > Subject: Re: new way of writing defconfigs for freescale's powerpc platforms > > On Thu, 2015-04-09 at 16:52 -0500, Pan Lijun-B44306 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? > > Will you accept this approach? > > I'm OK with a merge_config approach. > > I'm not OK with having separate builds for p1/p2/p4/t1/t2/b4. If we don't have separate build for p1/p2/p4/t1/t2/b4, in what way do we build for these SoC with merge_config approach? Do you have any suggestions? > > -Scott > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On 04/16/2015 12:44 AM, Bob Cochran wrote: On 04/09/2015 06:31 PM, Scott Wood wrote: On Thu, 2015-04-09 at 16:52 -0500, Pan Lijun-B44306 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? Will you accept this approach? I'm OK with a merge_config approach. I'm not OK with having separate builds for p1/p2/p4/t1/t2/b4. -Scott As you probably know, Freescale makes use of the Yocto Project build system for its SDK and submits patches to the SDK at a public meta-fsl-ppc repo at http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/ I have seen some kernel related patches in the past come across the Yocto Project site that made use of the Yocto Project kernel tools, which includes a process for maintaining kernel configuration fragments. Here is a link to a patch from a Freescale developer introducing Yocto kernel tool support (description files & configuration fragments) to the meta-fsl-ppc repo (FSL QorIQ SDK on Yocto). https://lists.yoctoproject.org/pipermail/meta-freescale/2014-October/010890.html It sounds like the requirements you have could be met with Yocto's existing process. I was hoping to see Freescale continue to move in the direction of using the Yocto kernel tools rather than roll its own solution. The Yocto kernel tools make use of description files (*.scc) and configuration fragments (*.cfg). Here is a link to the latest stable Yocto kernel development manual: http://www.yoctoproject.org/docs/1.7.1/kernel-dev/kernel-dev.html Bob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: new way of writing defconfigs for freescale's powerpc platforms
On 04/09/2015 06:31 PM, Scott Wood wrote: On Thu, 2015-04-09 at 16:52 -0500, Pan Lijun-B44306 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? Will you accept this approach? I'm OK with a merge_config approach. I'm not OK with having separate builds for p1/p2/p4/t1/t2/b4. -Scott As you probably know, Freescale makes use of the Yocto Project build system for its SDK and submits patches to the SDK at a public meta-fsl-ppc repo at http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/ I have seen some kernel related patches in the past come across the Yocto Project site that made use of the Yocto Project kernel tools, which includes a process for maintaining kernel configuration fragments. It sounds like the requirements you have could be met with Yocto's existing process. I was hoping to see Freescale continue to move in the direction of using the Yocto kernel tools rather than roll its own solution. The Yocto kernel tools make use of description files (*.scc) and configuration fragments (*.cfg). Here is a link to the latest stable Yocto kernel development manual: http://www.yoctoproject.org/docs/1.7.1/kernel-dev/kernel-dev.html Bob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
