new way of writing defconfigs for freescale's powerpc platforms

new way of writing defconfigs for freescale's powerpc platforms

[Lijun Pan]

Hi Maintainers,

We have a proposal for writing the defconfigs for freescale's powperpc plat=
forms 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 specif=
ic 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_confi=
g 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.=20
Why.  And our answer has been, it's arbitrary.=20
Some platform config files define it, and some platform config files don't.=
 =20
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 differ=
ent.=20
take for example corenet32_smp_defconfig and corenet64_smp_defconfig. =20
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. =20
Have a basic defconfig, then maybe have a fragment for 64 bit,=20
then fragments for particular platform differences, then a fragment for KVM=
,=20
and a fragment for ASF and so on."

Thanks
Lijun

Re: new way of writing defconfigs for freescale's powerpc platforms

[Scott Wood]

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

Re: new way of writing defconfigs for freescale's powerpc platforms

[Bob Cochran]

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
>

Re: new way of writing defconfigs for freescale's powerpc platforms

[Bob Cochran]

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

RE: new way of writing defconfigs for freescale's powerpc platforms

[Richard Schmitt]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQm9iIENvY2hyYW4gW21h
aWx0bzpwcGNAbWluZGNoYXNlcnMuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIw
MTUgODoyMSBBTQ0KPiBUbzogV29vZCBTY290dC1CMDc0MjE7IFBhbiBMaWp1bi1CNDQzMDYNCj4g
Q2M6IGxpbnV4cHBjLWRldkBvemxhYnMub3JnOyBTY2htaXR0IFJpY2hhcmQtQjQzMDgyDQo+IFN1
YmplY3Q6IFJlOiBuZXcgd2F5IG9mIHdyaXRpbmcgZGVmY29uZmlncyBmb3IgZnJlZXNjYWxlJ3Mg
cG93ZXJwYyBwbGF0Zm9ybXMNCj4gDQo+IE9uIDA0LzE2LzIwMTUgMTI6NDQgQU0sIEJvYiBDb2No
cmFuIHdyb3RlOg0KPiA+IE9uIDA0LzA5LzIwMTUgMDY6MzEgUE0sIFNjb3R0IFdvb2Qgd3JvdGU6
DQo+ID4+IE9uIFRodSwgMjAxNS0wNC0wOSBhdCAxNjo1MiAtMDUwMCwgUGFuIExpanVuLUI0NDMw
NiB3cm90ZToNCj4gPj4+IEhpIE1haW50YWluZXJzLA0KPiA+Pj4NCj4gPj4+IFdlIGhhdmUgYSBw
cm9wb3NhbCBmb3Igd3JpdGluZyB0aGUgZGVmY29uZmlncyBmb3IgZnJlZXNjYWxlJ3MNCj4gPj4+
IHBvd3BlcnBjIHBsYXRmb3JtcyBpbiBhIG5ldyB3YXkuDQo+ID4+PiBDYW4geW91IHRha2UgYSBs
b29rIGFuZCBwcm92aWRlIHNvbWUgZmVlZGJhY2s/DQo+ID4+Pg0KPiA+Pj4gWW91IGtub3cgY3Vy
cmVudGx5IHdlIGhhdmUgbXBjODV4eF9kZWZjb25maWcsIGNvcmVuZXQzMl9kZWZjb25maWcsDQo+
ID4+PiBic2M5MTN4X2RlZmNvbmZpZywgKmZtYW4qX2RlZmNvbmZpZywgZXRjLg0KPiA+Pj4gV2Ug
YXJlIGdvaW5nIHRvIGV4dHJhY3Qgc29tZSBjb21tb24gcGFydHMgZnJvbSB0aGUgZXhpc3RpbmcN
Cj4gPj4+IGRlZmNvbmZpZ3MsIGFuZCBuYW1lIGl0LCBzYXksIGZzbF9iYXNpY19kZWZjb25maWcu
DQo+ID4+PiBUaGVuLCB3ZSBjb3VsZCBjcmVhdGUgc29tZSBkZWZjb25maWdzIHRhcmdldGluZyBz
cGVjaWZpYyBmZWF0dXJlcyBvcg0KPiA+Pj4gc3BlY2lmaWMgcGxhdGZvcm1zLg0KPiA+Pj4gU2F5
LCBmZWF0dXJlcyBzcGVjaWZpYzoga3ZtX2RlZmNvbmZpZywgZm1hbl9kZWZjb25maWcsIGV0Yy4N
Cj4gPj4+IFBsYXRmb3JtcyBzcGVjaWZpYzogcDFfZGVmY29uZmlnLCBwMl9kZWZjb25nZmlnLCBw
NF9kZWZjb25maWcsDQo+ID4+PiB0MV9kZWZjb25maWcsIHQyX2RlZmNvbmZpZywgdDJfZGVmY29u
ZmlnLCBiNF9kZWZjb25maWcsIGV0YyBXaGVuIHdlDQo+ID4+PiB3YW50IHRvIG1ha2UgYSBrZXJu
ZWwgaW1hZ2UgZm9yIHAxIHBsYXRmb3JtLCBVc2luZyB0aGUgZm9sbG93aW5nDQo+ID4+PiBzdGVw
czoNCj4gPj4+DQo+ID4+PiBtYWtlIC4vc2NyaXB0cy9rY29uZmlnL21lcmdlX2NvbmZpZy5zaA0K
PiA+Pj4gYXJjaC9wb3dlcnBjL2NvbmZpZ3MvZnNsX2Jhc2ljX2NvbmZpZyBwMV9kZWZjb25maWcg
bWFrZQ0KPiA+Pj4NCj4gPj4+IFdoYXQgZG8geW91IHRoaW5rIG9mIHRoaXMgbmV3IGFwcHJvYWNo
Pw0KPiA+Pj4gV2lsbCB5b3UgYWNjZXB0IHRoaXMgYXBwcm9hY2g/DQo+ID4+DQo+ID4+IEknbSBP
SyB3aXRoIGEgbWVyZ2VfY29uZmlnIGFwcHJvYWNoLg0KPiA+Pg0KPiA+PiBJJ20gbm90IE9LIHdp
dGggaGF2aW5nIHNlcGFyYXRlIGJ1aWxkcyBmb3IgcDEvcDIvcDQvdDEvdDIvYjQuDQo+ID4+DQo+
ID4+IC1TY290dA0KPiA+DQo+ID4NCj4gPiBBcyB5b3UgcHJvYmFibHkga25vdywgRnJlZXNjYWxl
IG1ha2VzIHVzZSBvZiB0aGUgWW9jdG8gUHJvamVjdCBidWlsZA0KPiA+IHN5c3RlbSBmb3IgaXRz
IFNESyBhbmQgc3VibWl0cyBwYXRjaGVzIHRvIHRoZSBTREsgYXQgYSBwdWJsaWMNCj4gPiBtZXRh
LWZzbC1wcGMgcmVwbyBhdA0KPiA+IGh0dHA6Ly9naXQueW9jdG9wcm9qZWN0Lm9yZy9jZ2l0L2Nn
aXQuY2dpL21ldGEtZnNsLXBwYy8NCj4gPg0KPiA+IEkgaGF2ZSBzZWVuIHNvbWUga2VybmVsIHJl
bGF0ZWQgcGF0Y2hlcyBpbiB0aGUgcGFzdCBjb21lIGFjcm9zcyB0aGUNCj4gPiBZb2N0byBQcm9q
ZWN0IHNpdGUgdGhhdCBtYWRlIHVzZSBvZiB0aGUgWW9jdG8gUHJvamVjdCBrZXJuZWwgdG9vbHMs
DQo+ID4gd2hpY2ggaW5jbHVkZXMgYSBwcm9jZXNzIGZvciBtYWludGFpbmluZyBrZXJuZWwgY29u
ZmlndXJhdGlvbiBmcmFnbWVudHMuDQo+IA0KPiANCj4gSGVyZSBpcyBhIGxpbmsgdG8gYSBwYXRj
aCBmcm9tIGEgRnJlZXNjYWxlIGRldmVsb3BlciBpbnRyb2R1Y2luZyBZb2N0byBrZXJuZWwNCj4g
dG9vbCBzdXBwb3J0IChkZXNjcmlwdGlvbiBmaWxlcyAmIGNvbmZpZ3VyYXRpb24gZnJhZ21lbnRz
KSB0byB0aGUgbWV0YS1mc2wtcHBjDQo+IHJlcG8gKEZTTCBRb3JJUSBTREsgb24gWW9jdG8pLg0K
PiANCj4gaHR0cHM6Ly9saXN0cy55b2N0b3Byb2plY3Qub3JnL3BpcGVybWFpbC9tZXRhLWZyZWVz
Y2FsZS8yMDE0LQ0KPiBPY3RvYmVyLzAxMDg5MC5odG1sDQo+IA0KPiANClllcywgd2UgZG8gYWxz
byBpbnRlbmQgdG8gc3VwcG9ydCB0aGlzIGluIFlvY3RvIGFuZCB0aGF0IHRoZSBmcmFnbWVudHMg
d2lsbCBiZSBhcHBsaWVkIGR1cmluZyB0aGUgYnVpbGQgcHJvY2VzcyBhcyBwYXJ0IG9mIFlvY3Rv
IHJlY2lwZXMgYW5kIEtlcm5lbCBGZWF0dXJlcy4gICBUaGUgZmlyc3Qgc3RlcCBpbiBkb2luZyB0
aGlzIGlzIGNyZWF0aW5nIHRoZSBmcmFnbWVudHMgYW5kIHByb3ZpZGluZyBhIG1lYW5zIHRvIGNy
ZWF0ZSB0aGUgcGxhdGZvcm0gZGVmY29uZmlncyB3aXRob3V0IFlvY3RvLiAgDQo+IA0KPiA+ICAg
SXQgc291bmRzIGxpa2UgdGhlIHJlcXVpcmVtZW50cyB5b3UgaGF2ZSBjb3VsZCBiZSBtZXQgd2l0
aCBZb2N0bydzDQo+ID4gZXhpc3RpbmcgcHJvY2Vzcy4NCj4gPg0KPiA+IEkgd2FzIGhvcGluZyB0
byBzZWUgRnJlZXNjYWxlIGNvbnRpbnVlIHRvIG1vdmUgaW4gdGhlIGRpcmVjdGlvbiBvZg0KPiA+
IHVzaW5nIHRoZSBZb2N0byBrZXJuZWwgdG9vbHMgcmF0aGVyIHRoYW4gcm9sbCBpdHMgb3duIHNv
bHV0aW9uLg0KDQpUaGVyZSBhcmUgYSBudW1iZXIgb2YgYWN0aXZpdGllcyB3ZSBhcmUgZG9pbmcg
dGhhdCB3aWxsIGJyaW5nIHVzIG1vcmUgaW4gdGhlIGRpcmVjdGlvbiBvZiB0aGUgWW9jdG8ga2Vy
bmVsIHRvb2xzLiAgQnV0IGFnYWluLCBZb2N0byBpcyBvbmUgd2F5LCBub3QgdGhlIG9ubHkgd2F5
LiAgU28gd2UgaW50ZW5kIHRvIHN1cHBvcnQgYSBNYWtlZmlsZSBhcHByb2FjaCB0byBidWlsZGlu
ZyBjb25maWdzIChzaW1pbGFyIHRvIEludGVsKSBhcyB3ZWxsIGFzIGEgWW9jdG8gYXBwcm9hY2gg
dG8gYnVpbGRpbmcgY29uZmlncy4NCj4gPg0KPiA+IFRoZSBZb2N0byBrZXJuZWwgdG9vbHMgbWFr
ZSB1c2Ugb2YgZGVzY3JpcHRpb24gZmlsZXMgKCouc2NjKSBhbmQNCj4gPiBjb25maWd1cmF0aW9u
IGZyYWdtZW50cyAoKi5jZmcpLg0KPiA+DQo+ID4gSGVyZSBpcyBhIGxpbmsgdG8gdGhlIGxhdGVz
dCBzdGFibGUgWW9jdG8ga2VybmVsIGRldmVsb3BtZW50IG1hbnVhbDoNCj4gPiBodHRwOi8vd3d3
LnlvY3RvcHJvamVjdC5vcmcvZG9jcy8xLjcuMS9rZXJuZWwtZGV2L2tlcm5lbC1kZXYuaHRtbA0K
PiA+DQo+ID4gQm9iDQo+ID4NCj4gPg0KUmljaA0KDQo+ID4NCj4gPg0KPiA+DQo+ID4+DQo+ID4+
DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
ID4+IExpbnV4cHBjLWRldiBtYWlsaW5nIGxpc3QNCj4gPj4gTGludXhwcGMtZGV2QGxpc3RzLm96
bGFicy5vcmcNCj4gPj4gaHR0cHM6Ly9saXN0cy5vemxhYnMub3JnL2xpc3RpbmZvL2xpbnV4cHBj
LWRldg0KPiA+Pg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCj4gPiBMaW51eHBwYy1kZXYgbWFpbGluZyBsaXN0DQo+ID4gTGludXhwcGMt
ZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gPiBodHRwczovL2xpc3RzLm96bGFicy5vcmcvbGlzdGlu
Zm8vbGludXhwcGMtZGV2DQoNCg==

Re: new way of writing defconfigs for freescale's powerpc platforms

[Scott Wood]

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

RE: new way of writing defconfigs for freescale's powerpc platforms

[Lijun Pan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDA5LCAyMDE1IDU6MzEgUE0NCj4gVG86IFBhbiBM
aWp1bi1CNDQzMDYNCj4gQ2M6IGxpbnV4cHBjLWRldkBvemxhYnMub3JnOyBTY2htaXR0IFJpY2hh
cmQtQjQzMDgyDQo+IFN1YmplY3Q6IFJlOiBuZXcgd2F5IG9mIHdyaXRpbmcgZGVmY29uZmlncyBm
b3IgZnJlZXNjYWxlJ3MgcG93ZXJwYyBwbGF0Zm9ybXMNCj4gDQo+IE9uIFRodSwgMjAxNS0wNC0w
OSBhdCAxNjo1MiAtMDUwMCwgUGFuIExpanVuLUI0NDMwNiB3cm90ZToNCj4gPiBIaSBNYWludGFp
bmVycywNCj4gPg0KPiA+IFdlIGhhdmUgYSBwcm9wb3NhbCBmb3Igd3JpdGluZyB0aGUgZGVmY29u
ZmlncyBmb3IgZnJlZXNjYWxlJ3MgcG93cGVycGMNCj4gcGxhdGZvcm1zIGluIGEgbmV3IHdheS4N
Cj4gPiBDYW4geW91IHRha2UgYSBsb29rIGFuZCBwcm92aWRlIHNvbWUgZmVlZGJhY2s/DQo+ID4N
Cj4gPiBZb3Uga25vdyBjdXJyZW50bHkgd2UgaGF2ZSBtcGM4NXh4X2RlZmNvbmZpZywgY29yZW5l
dDMyX2RlZmNvbmZpZywNCj4gYnNjOTEzeF9kZWZjb25maWcsICpmbWFuKl9kZWZjb25maWcsIGV0
Yy4NCj4gPiBXZSBhcmUgZ29pbmcgdG8gZXh0cmFjdCBzb21lIGNvbW1vbiBwYXJ0cyBmcm9tIHRo
ZSBleGlzdGluZyBkZWZjb25maWdzLA0KPiBhbmQgbmFtZSBpdCwgc2F5LCBmc2xfYmFzaWNfZGVm
Y29uZmlnLg0KPiA+IFRoZW4sIHdlIGNvdWxkIGNyZWF0ZSBzb21lIGRlZmNvbmZpZ3MgdGFyZ2V0
aW5nIHNwZWNpZmljIGZlYXR1cmVzIG9yIHNwZWNpZmljDQo+IHBsYXRmb3Jtcy4NCj4gPiBTYXks
IGZlYXR1cmVzIHNwZWNpZmljOiBrdm1fZGVmY29uZmlnLCBmbWFuX2RlZmNvbmZpZywgZXRjLg0K
PiA+IFBsYXRmb3JtcyBzcGVjaWZpYzogcDFfZGVmY29uZmlnLCBwMl9kZWZjb25nZmlnLCBwNF9k
ZWZjb25maWcsDQo+ID4gdDFfZGVmY29uZmlnLCB0Ml9kZWZjb25maWcsIHQyX2RlZmNvbmZpZywg
YjRfZGVmY29uZmlnLCBldGMgV2hlbiB3ZQ0KPiA+IHdhbnQgdG8gbWFrZSBhIGtlcm5lbCBpbWFn
ZSBmb3IgcDEgcGxhdGZvcm0sIFVzaW5nIHRoZSBmb2xsb3dpbmcgc3RlcHM6DQo+ID4NCj4gPiBt
YWtlIC4vc2NyaXB0cy9rY29uZmlnL21lcmdlX2NvbmZpZy5zaA0KPiA+IGFyY2gvcG93ZXJwYy9j
b25maWdzL2ZzbF9iYXNpY19jb25maWcgcDFfZGVmY29uZmlnIG1ha2UNCj4gPg0KPiA+IFdoYXQg
ZG8geW91IHRoaW5rIG9mIHRoaXMgbmV3IGFwcHJvYWNoPw0KPiA+IFdpbGwgeW91IGFjY2VwdCB0
aGlzIGFwcHJvYWNoPw0KPiANCj4gSSdtIE9LIHdpdGggYSBtZXJnZV9jb25maWcgYXBwcm9hY2gu
DQo+IA0KPiBJJ20gbm90IE9LIHdpdGggaGF2aW5nIHNlcGFyYXRlIGJ1aWxkcyBmb3IgcDEvcDIv
cDQvdDEvdDIvYjQuDQoNCklmIHdlIGRvbid0IGhhdmUgc2VwYXJhdGUgYnVpbGQgZm9yIHAxL3Ay
L3A0L3QxL3QyL2I0LCBpbiB3aGF0IHdheSBkbyB3ZQ0KYnVpbGQgZm9yIHRoZXNlIFNvQyB3aXRo
IG1lcmdlX2NvbmZpZyBhcHByb2FjaD8gRG8geW91IGhhdmUgYW55IHN1Z2dlc3Rpb25zPyANCg0K
PiANCj4gLVNjb3R0DQo+IA0KDQo=

Re: new way of writing defconfigs for freescale's powerpc platforms

[Michael Ellerman]

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.

cheers

Re: new way of writing defconfigs for freescale's powerpc platforms

[Scott Wood]

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

Re: new way of writing defconfigs for freescale's powerpc platforms

[Michael Ellerman]

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/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

RE: new way of writing defconfigs for freescale's powerpc platforms

[Lijun Pan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWljaGFlbCBFbGxlcm1h
biBbbWFpbHRvOm1wZUBlbGxlcm1hbi5pZC5hdV0NCj4gU2VudDogRnJpZGF5LCBBcHJpbCAxNywg
MjAxNSAxOjE5IEFNDQo+IFRvOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiBDYzogUGFuIExpanVuLUI0
NDMwNjsgbGludXhwcGMtZGV2QG96bGFicy5vcmc7IFNjaG1pdHQgUmljaGFyZC1CNDMwODINCj4g
U3ViamVjdDogUmU6IG5ldyB3YXkgb2Ygd3JpdGluZyBkZWZjb25maWdzIGZvciBmcmVlc2NhbGUn
cyBwb3dlcnBjIHBsYXRmb3Jtcw0KPiANCj4gT24gVGh1LCAyMDE1LTA0LTE2IGF0IDIzOjEzIC0w
NTAwLCBTY290dCBXb29kIHdyb3RlOg0KPiA+IE9uIEZyaSwgMjAxNS0wNC0xNyBhdCAxMDo1NCAr
MTAwMCwgTWljaGFlbCBFbGxlcm1hbiB3cm90ZToNCj4gPiA+IE9uIFRodSwgMjAxNS0wNC0wOSBh
dCAyMTo1MiArMDAwMCwgTGlqdW4gUGFuIHdyb3RlOg0KPiA+ID4gPiBIaSBNYWludGFpbmVycywN
Cj4gPiA+ID4NCj4gPiA+ID4gV2UgaGF2ZSBhIHByb3Bvc2FsIGZvciB3cml0aW5nIHRoZSBkZWZj
b25maWdzIGZvciBmcmVlc2NhbGUncyBwb3dwZXJwYw0KPiBwbGF0Zm9ybXMgaW4gYSBuZXcgd2F5
Lg0KPiA+ID4gPiBDYW4geW91IHRha2UgYSBsb29rIGFuZCBwcm92aWRlIHNvbWUgZmVlZGJhY2s/
DQo+ID4gPiA+DQo+ID4gPiA+IFlvdSBrbm93IGN1cnJlbnRseSB3ZSBoYXZlIG1wYzg1eHhfZGVm
Y29uZmlnLCBjb3JlbmV0MzJfZGVmY29uZmlnLA0KPiBic2M5MTN4X2RlZmNvbmZpZywgKmZtYW4q
X2RlZmNvbmZpZywgZXRjLg0KPiA+ID4gPiBXZSBhcmUgZ29pbmcgdG8gZXh0cmFjdCBzb21lIGNv
bW1vbiBwYXJ0cyBmcm9tIHRoZSBleGlzdGluZyBkZWZjb25maWdzLA0KPiBhbmQgbmFtZSBpdCwg
c2F5LCBmc2xfYmFzaWNfZGVmY29uZmlnLg0KPiA+ID4gPiBUaGVuLCB3ZSBjb3VsZCBjcmVhdGUg
c29tZSBkZWZjb25maWdzIHRhcmdldGluZyBzcGVjaWZpYyBmZWF0dXJlcyBvcg0KPiBzcGVjaWZp
YyBwbGF0Zm9ybXMuDQo+ID4gPiA+IFNheSwgZmVhdHVyZXMgc3BlY2lmaWM6IGt2bV9kZWZjb25m
aWcsIGZtYW5fZGVmY29uZmlnLCBldGMuDQo+ID4gPiA+IFBsYXRmb3JtcyBzcGVjaWZpYzogcDFf
ZGVmY29uZmlnLCBwMl9kZWZjb25nZmlnLCBwNF9kZWZjb25maWcsDQo+ID4gPiA+IHQxX2RlZmNv
bmZpZywgdDJfZGVmY29uZmlnLCB0Ml9kZWZjb25maWcsIGI0X2RlZmNvbmZpZywgZXRjIFdoZW4N
Cj4gPiA+ID4gd2Ugd2FudCB0byBtYWtlIGEga2VybmVsIGltYWdlIGZvciBwMSBwbGF0Zm9ybSwg
VXNpbmcgdGhlIGZvbGxvd2luZw0KPiBzdGVwczoNCj4gPiA+ID4NCj4gPiA+ID4gbWFrZSAuL3Nj
cmlwdHMva2NvbmZpZy9tZXJnZV9jb25maWcuc2gNCj4gPiA+ID4gYXJjaC9wb3dlcnBjL2NvbmZp
Z3MvZnNsX2Jhc2ljX2NvbmZpZyBwMV9kZWZjb25maWcgbWFrZQ0KPiA+ID4gPg0KPiA+ID4gPiBX
aGF0IGRvIHlvdSB0aGluayBvZiB0aGlzIG5ldyBhcHByb2FjaD8NCj4gPiA+DQo+ID4gPiBJIGRv
bid0IGxpa2UgdGhhdCB0aGUgdXNlciBoYXMgdG8gbWFudWFsbHkgcnVuIG1lcmdlX2NvbmZpZy5z
aC4NCj4gPiA+DQo+ID4gPiBIb3cgZG9lcyBhIHVzZXIgZXZlbiBrbm93IHRoYXQgaXQncyBhbiBv
cHRpb24/DQo+ID4gPg0KPiA+ID4gSXQgYWxzbyBicmVha3Mgc2NyaXB0cyB0aGF0IGF1dG8gYnVp
bGQgdGhlIGtlcm5lbCwgd2hpY2ggZXhwZWN0IHRvIGJlIGFibGUgdG8NCj4gZG86DQo+ID4gPg0K
PiA+ID4gICAkIG1ha2UgZm9vX2RlZmNvbmZpZw0KPiA+ID4gICAkIG1ha2UNCj4gPiA+DQo+ID4g
PiBTY3JpcHRzIGxpa2UgbWluZSBmb3IgZXhhbXBsZSA6KQ0KPiA+ID4NCj4gPiA+ICAgaHR0cDov
L2tpc3NrYi5lbGxlcm1hbi5pZC5hdS9raXNza2IvaGVhZC84NzM0Lw0KPiA+ID4NCj4gPiA+IFdo
YXQgSSdkIGJlIGhhcHB5IHdpdGggaXMgc29tZXRoaW5nIHRoYXQgZG9lcyBtZXJnZV9jb25maWcg
dW5kZXIgdGhlDQo+ID4gPiBjb3ZlcnMuIFNvIGEgdXNlciBzdGlsbCBydW5zICdtYWtlIGZzbF9w
bGF0X2Zvb19kZWZjb25maWcnLCBidXQNCj4gPiA+IHVuZGVyIHRoZSBjb3ZlcnMgaXQgZG9lcyBh
IG1lcmdlIGNvbmZpZy4NCj4gPiA+DQo+ID4gPiBrdm1jb25maWcgYW5kIHRpbnljb25maWcgYXJl
IGltcGxlbWVudGVkIHRoYXQgd2F5IGFscmVhZHksIHNvIHdpdGggYQ0KPiA+ID4gYml0IG1vcmUg
d29yayBob3BlZnVsbHkgeW91IGNhbiBkbyB0aGF0IGZvciBhcmNoIGNvbmZpZ3MgYWxzby4NCj4g
Pg0KPiA+IGt2bWNvbmZpZyBhbmQgdGlueWNvbmZpZyBhcmUgc3RpbGwgc2VwYXJhdGUgdXNlci12
aXNpYmxlIHN0ZXBzIHRvIGJlDQo+ID4gYXBwbGllZCBhZnRlciBydW5uaW5nIGEgYmFzZSBkZWZj
b25maWcuDQo+IA0KPiBOb3QgYXMgb2YgcmVjZW50bHk6DQo+IA0KPiANCj4gaHR0cHM6Ly9naXQu
a2VybmVsLm9yZy9jZ2l0L2xpbnV4L2tlcm5lbC9naXQvdG9ydmFsZHMvbGludXguZ2l0L2NvbW1p
dC9zY3JpcHRzL2tjDQo+IG9uZmlnL01ha2VmaWxlP2lkPTYzYTkxMDMzZDUyZTY0YTIyZTU3MWZl
ODQ5MjRjMGI3ZjIxYzI4MGQNCj4gDQoNCkFib3ZlIHBhdGNoIGlzIHZlcnkgZ2VuZXJpYy4NCldp
dGggdGhpcyBwYXRjaCwgd2UgZG9uJ3QgZXZlbiBuZWVkIHRvIG1vZGlmeSBhcmNoL3Bvd2VycGMv
TWFrZWZpbGUuDQpXZSBjYW4ganVzdCBhZGQgZnJhZ21lbnRzIChsaWtlIHNtcC5jb25maWcsIGt2
bV9ndWVzdC5jb25maWcsIGV0YykgdW5kZXINCmFyY2gvcG93ZXJwYy9jb25maWdzLyBvcg0KYWRk
IHBsYXRmb3JtIGluZGVwZW5kZW50IGNvbmZpZyB1bmRlciBrZXJuZWwvY29uZmlncy8NCg0KZXhh
bXBsZSBtaWdodCBiZToNCm1ha2UgbXBjODV4eF9kZWZjb25maWcNCm1ha2Ugc21wLmNvbmZpZw0K
bWFrZSBrdm1fZ3Vlc3QuY29uZmlnDQoNCj4gDQo+IFdoaWNoIHByZXR0eSBtdWNoIGRvZXMgd2hh
dCB5b3UgZGVzY3JpYmUgYmVsb3cgSSB0aGluay4NCj4gDQo+ID4gRm9yIGJyZWFraW5nIGEgcGxh
dGZvcm0gZGVmY29uZmlnIGludG8gY29tcG9uZW50cywgd2UgY291bGQgZG8NCj4gPiBzb21ldGhp
bmcgbGlrZSB0aGlzIGluIGFyY2gvcG93ZXJwYy9NYWtlZmlsZToNCj4gPg0KPiA+ICMgQ2FuJ3Qg
Y2FsbCBtZXJnZWNvbmZpZyBkaXJlY3RseSBhcyBpdCBpc24ndCBkZWZpbmVkIGF0IHRoaXMgcG9p
bnQNCj4gPiBkZWZpbmUgZG9tZXJnZQ0KPiA+ICAgICAgICBAJChNQUtFKSAtZiAkKHNyY3RyZWUp
L3NjcmlwdHMva2NvbmZpZy9NYWtlZmlsZSAkKDEpLmNvbmZpZw0KPiA+IGVuZGVmDQo+ID4NCj4g
PiBjb3JlbmV0NjRfc21wX2RlZmNvbmZpZzogY29yZW5ldDY0X2Jhc2ljX2RlZmNvbmZpZw0KPiA+
IAkkKGNhbGwgZG9tZXJnZSxzbXApDQo+ID4gCSQoY2FsbCBkb21lcmdlLGFsdGl2ZWMpDQo+ID4g
CSQoY2FsbCBkb21lcmdlLGNvcmVuZXRfZHJpdmVycykNCj4gPiAJJChjYWxsIGRvbWVyZ2UsZW1i
ZWRkZWRfbWlzYykgIyBmaWxlc3lzdGVtcyBldGMNCj4gPg0KPiA+IEFuZCB0aGlzIGluIHNjcmlw
dHMva2NvbmZpZy9NYWtlZmlsZToNCj4gPg0KPiA+ICUuY29uZmlnOg0KPiA+ICAgICAgICAkKGNh
bGwgbWVyZ2Vjb25maWcsJCopDQo+ID4NCj4gPiBPbmUgaXNzdWUgd2l0aCB0aGlzIGlzIHRoYXQg
d2UnZCBsb3NlIHRoZSBhYmlsaXR5IHRvIHVzZSBzYXZlZGVmY29uZmlnDQo+ID4gKGF0IGxlYXN0
IHdpdGhvdXQgbWFudWFsIG1hbmlwdWxhdGlvbiBvZiB0aGUgcmVzdWx0cykgdG8gbWFpbnRhaW4g
dGhlDQo+ID4gZGVmY29uZmlncy9mcmFnbWVudHMuDQo+IA0KPiBUaGF0J3MgcHJvYmFibHkgT0ss
IGl0J3Mgb25seSBtYWludGFpbmVycyB3aG8gbmVlZCB0byBkbyB0aGF0Lg0KPiANCj4gY2hlZXJz
DQo+IA0KDQo=

Re: new way of writing defconfigs for freescale's powerpc platforms

[Scott Wood]

On Fri, 2015-04-17 at 13:50 -0500, Pan Lijun-B44306 wrote:
> 
> 
> > -----Original Message-----
> > From: Michael Ellerman [mailto:mpe@ellerman.id.au]
> > Sent: Friday, April 17, 2015 1:19 AM
> > To: Wood Scott-B07421
> > Cc: Pan Lijun-B44306; linuxppc-dev@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/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

RE: new way of writing defconfigs for freescale's powerpc platforms

[Lijun Pan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogRnJpZGF5LCBBcHJpbCAxNywgMjAxNSAxOjUzIFBNDQo+IFRvOiBQYW4gTGlq
dW4tQjQ0MzA2DQo+IENjOiBNaWNoYWVsIEVsbGVybWFuOyBsaW51eHBwYy1kZXZAb3psYWJzLm9y
ZzsgU2NobWl0dCBSaWNoYXJkLUI0MzA4Mg0KPiBTdWJqZWN0OiBSZTogbmV3IHdheSBvZiB3cml0
aW5nIGRlZmNvbmZpZ3MgZm9yIGZyZWVzY2FsZSdzIHBvd2VycGMgcGxhdGZvcm1zDQo+IA0KPiBP
biBGcmksIDIwMTUtMDQtMTcgYXQgMTM6NTAgLTA1MDAsIFBhbiBMaWp1bi1CNDQzMDYgd3JvdGU6
DQo+ID4NCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206
IE1pY2hhZWwgRWxsZXJtYW4gW21haWx0bzptcGVAZWxsZXJtYW4uaWQuYXVdDQo+ID4gPiBTZW50
OiBGcmlkYXksIEFwcmlsIDE3LCAyMDE1IDE6MTkgQU0NCj4gPiA+IFRvOiBXb29kIFNjb3R0LUIw
NzQyMQ0KPiA+ID4gQ2M6IFBhbiBMaWp1bi1CNDQzMDY7IGxpbnV4cHBjLWRldkBvemxhYnMub3Jn
OyBTY2htaXR0DQo+ID4gPiBSaWNoYXJkLUI0MzA4Mg0KPiA+ID4gU3ViamVjdDogUmU6IG5ldyB3
YXkgb2Ygd3JpdGluZyBkZWZjb25maWdzIGZvciBmcmVlc2NhbGUncyBwb3dlcnBjDQo+ID4gPiBw
bGF0Zm9ybXMNCj4gPiA+DQo+ID4gPiBPbiBUaHUsIDIwMTUtMDQtMTYgYXQgMjM6MTMgLTA1MDAs
IFNjb3R0IFdvb2Qgd3JvdGU6DQo+ID4gPiA+IE9uIEZyaSwgMjAxNS0wNC0xNyBhdCAxMDo1NCAr
MTAwMCwgTWljaGFlbCBFbGxlcm1hbiB3cm90ZToNCj4gPiA+ID4gPiBPbiBUaHUsIDIwMTUtMDQt
MDkgYXQgMjE6NTIgKzAwMDAsIExpanVuIFBhbiB3cm90ZToNCj4gPiA+ID4gPiA+IEhpIE1haW50
YWluZXJzLA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IFdlIGhhdmUgYSBwcm9wb3NhbCBmb3Ig
d3JpdGluZyB0aGUgZGVmY29uZmlncyBmb3IgZnJlZXNjYWxlJ3MNCj4gPiA+ID4gPiA+IHBvd3Bl
cnBjDQo+ID4gPiBwbGF0Zm9ybXMgaW4gYSBuZXcgd2F5Lg0KPiA+ID4gPiA+ID4gQ2FuIHlvdSB0
YWtlIGEgbG9vayBhbmQgcHJvdmlkZSBzb21lIGZlZWRiYWNrPw0KPiA+ID4gPiA+ID4NCj4gPiA+
ID4gPiA+IFlvdSBrbm93IGN1cnJlbnRseSB3ZSBoYXZlIG1wYzg1eHhfZGVmY29uZmlnLA0KPiA+
ID4gPiA+ID4gY29yZW5ldDMyX2RlZmNvbmZpZywNCj4gPiA+IGJzYzkxM3hfZGVmY29uZmlnLCAq
Zm1hbipfZGVmY29uZmlnLCBldGMuDQo+ID4gPiA+ID4gPiBXZSBhcmUgZ29pbmcgdG8gZXh0cmFj
dCBzb21lIGNvbW1vbiBwYXJ0cyBmcm9tIHRoZSBleGlzdGluZw0KPiA+ID4gPiA+ID4gZGVmY29u
ZmlncywNCj4gPiA+IGFuZCBuYW1lIGl0LCBzYXksIGZzbF9iYXNpY19kZWZjb25maWcuDQo+ID4g
PiA+ID4gPiBUaGVuLCB3ZSBjb3VsZCBjcmVhdGUgc29tZSBkZWZjb25maWdzIHRhcmdldGluZyBz
cGVjaWZpYw0KPiA+ID4gPiA+ID4gZmVhdHVyZXMgb3INCj4gPiA+IHNwZWNpZmljIHBsYXRmb3Jt
cy4NCj4gPiA+ID4gPiA+IFNheSwgZmVhdHVyZXMgc3BlY2lmaWM6IGt2bV9kZWZjb25maWcsIGZt
YW5fZGVmY29uZmlnLCBldGMuDQo+ID4gPiA+ID4gPiBQbGF0Zm9ybXMgc3BlY2lmaWM6IHAxX2Rl
ZmNvbmZpZywgcDJfZGVmY29uZ2ZpZywgcDRfZGVmY29uZmlnLA0KPiA+ID4gPiA+ID4gdDFfZGVm
Y29uZmlnLCB0Ml9kZWZjb25maWcsIHQyX2RlZmNvbmZpZywgYjRfZGVmY29uZmlnLCBldGMNCj4g
PiA+ID4gPiA+IFdoZW4gd2Ugd2FudCB0byBtYWtlIGEga2VybmVsIGltYWdlIGZvciBwMSBwbGF0
Zm9ybSwgVXNpbmcgdGhlDQo+ID4gPiA+ID4gPiBmb2xsb3dpbmcNCj4gPiA+IHN0ZXBzOg0KPiA+
ID4gPiA+ID4NCj4gPiA+ID4gPiA+IG1ha2UgLi9zY3JpcHRzL2tjb25maWcvbWVyZ2VfY29uZmln
LnNoDQo+ID4gPiA+ID4gPiBhcmNoL3Bvd2VycGMvY29uZmlncy9mc2xfYmFzaWNfY29uZmlnIHAx
X2RlZmNvbmZpZyBtYWtlDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gV2hhdCBkbyB5b3UgdGhp
bmsgb2YgdGhpcyBuZXcgYXBwcm9hY2g/DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJIGRvbid0IGxp
a2UgdGhhdCB0aGUgdXNlciBoYXMgdG8gbWFudWFsbHkgcnVuIG1lcmdlX2NvbmZpZy5zaC4NCj4g
PiA+ID4gPg0KPiA+ID4gPiA+IEhvdyBkb2VzIGEgdXNlciBldmVuIGtub3cgdGhhdCBpdCdzIGFu
IG9wdGlvbj8NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEl0IGFsc28gYnJlYWtzIHNjcmlwdHMgdGhh
dCBhdXRvIGJ1aWxkIHRoZSBrZXJuZWwsIHdoaWNoIGV4cGVjdA0KPiA+ID4gPiA+IHRvIGJlIGFi
bGUgdG8NCj4gPiA+IGRvOg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICAkIG1ha2UgZm9vX2RlZmNv
bmZpZw0KPiA+ID4gPiA+ICAgJCBtYWtlDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBTY3JpcHRzIGxp
a2UgbWluZSBmb3IgZXhhbXBsZSA6KQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICBodHRwOi8va2lz
c2tiLmVsbGVybWFuLmlkLmF1L2tpc3NrYi9oZWFkLzg3MzQvDQo+ID4gPiA+ID4NCj4gPiA+ID4g
PiBXaGF0IEknZCBiZSBoYXBweSB3aXRoIGlzIHNvbWV0aGluZyB0aGF0IGRvZXMgbWVyZ2VfY29u
ZmlnIHVuZGVyDQo+ID4gPiA+ID4gdGhlIGNvdmVycy4gU28gYSB1c2VyIHN0aWxsIHJ1bnMgJ21h
a2UgZnNsX3BsYXRfZm9vX2RlZmNvbmZpZycsDQo+ID4gPiA+ID4gYnV0IHVuZGVyIHRoZSBjb3Zl
cnMgaXQgZG9lcyBhIG1lcmdlIGNvbmZpZy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IGt2bWNvbmZp
ZyBhbmQgdGlueWNvbmZpZyBhcmUgaW1wbGVtZW50ZWQgdGhhdCB3YXkgYWxyZWFkeSwgc28NCj4g
PiA+ID4gPiB3aXRoIGEgYml0IG1vcmUgd29yayBob3BlZnVsbHkgeW91IGNhbiBkbyB0aGF0IGZv
ciBhcmNoIGNvbmZpZ3MgYWxzby4NCj4gPiA+ID4NCj4gPiA+ID4ga3ZtY29uZmlnIGFuZCB0aW55
Y29uZmlnIGFyZSBzdGlsbCBzZXBhcmF0ZSB1c2VyLXZpc2libGUgc3RlcHMgdG8NCj4gPiA+ID4g
YmUgYXBwbGllZCBhZnRlciBydW5uaW5nIGEgYmFzZSBkZWZjb25maWcuDQo+ID4gPg0KPiA+ID4g
Tm90IGFzIG9mIHJlY2VudGx5Og0KPiA+ID4NCj4gPiA+DQo+ID4gPiBodHRwczovL2dpdC5rZXJu
ZWwub3JnL2NnaXQvbGludXgva2VybmVsL2dpdC90b3J2YWxkcy9saW51eC5naXQvY29tbQ0KPiA+
ID4gaXQvc2NyaXB0cy9rYw0KPiA+ID4gb25maWcvTWFrZWZpbGU/aWQ9NjNhOTEwMzNkNTJlNjRh
MjJlNTcxZmU4NDkyNGMwYjdmMjFjMjgwZA0KPiA+ID4NCj4gPg0KPiA+IEFib3ZlIHBhdGNoIGlz
IHZlcnkgZ2VuZXJpYy4NCj4gPiBXaXRoIHRoaXMgcGF0Y2gsIHdlIGRvbid0IGV2ZW4gbmVlZCB0
byBtb2RpZnkgYXJjaC9wb3dlcnBjL01ha2VmaWxlLg0KPiA+IFdlIGNhbiBqdXN0IGFkZCBmcmFn
bWVudHMgKGxpa2Ugc21wLmNvbmZpZywga3ZtX2d1ZXN0LmNvbmZpZywgZXRjKQ0KPiA+IHVuZGVy
IGFyY2gvcG93ZXJwYy9jb25maWdzLyBvciBhZGQgcGxhdGZvcm0gaW5kZXBlbmRlbnQgY29uZmln
IHVuZGVyDQo+ID4ga2VybmVsL2NvbmZpZ3MvDQo+ID4NCj4gPiBleGFtcGxlIG1pZ2h0IGJlOg0K
PiA+IG1ha2UgbXBjODV4eF9kZWZjb25maWcNCj4gPiBtYWtlIHNtcC5jb25maWcNCj4gPiBtYWtl
IGt2bV9ndWVzdC5jb25maWcNCj4gDQo+IFRoZSBwb2ludCBpcyB0aGF0IHRoZSB1c2VyIHNob3Vs
ZCBub3QgaGF2ZSB0byBkbyB0aGF0LiAgVGhleSBjYW4gaWYgdGhleSB3YW50LA0KPiBidXQgdGhl
cmUgc2hvdWxkIHN0aWxsIGJlIHRyYWRpdGlvbmFsIG5hbWVkIGNvbmZpZ3MsIHdoaWNoIHdvdWxk
IGp1c3Qgd29yaw0KPiBkaWZmZXJlbnRseSB1bmRlciB0aGUgaG9vZC4NCj4gDQo+IC1TY290dA0K
PiANCg0KSGF2ZSBqdXN0IHNlbnQgb3V0IGEgcGF0Y2ggY29uc2lkZXJpbmcgdGhlIHByZXZpb3Vz
IGRpc2N1c3Npb24uDQpodHRwOi8vcGF0Y2h3b3JrLm96bGFicy5vcmcvcGF0Y2gvNDYyMjQ5Lw0K
W1BBVENIXSBwb3dlcnBjL2RlZmNvbmZpZzogbmV3IHdheSBvZiB3cml0aW5nIGRlZmNvbmZpZw0K
DQo=

Re: new way of writing defconfigs for freescale's powerpc platforms

[Timur Tabi]

On Fri, Apr 17, 2015 at 11:53 PM, Lijun Pan <Lijun.Pan@freescale.com> 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.

Re: new way of writing defconfigs for freescale's powerpc platforms

[Scott Wood]

On Sat, 2015-04-18 at 08:46 -0500, Timur Tabi wrote:
> On Fri, Apr 17, 2015 at 11:53 PM, Lijun Pan <Lijun.Pan@freescale.com> 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

Re: new way of writing defconfigs for freescale's powerpc platforms

[Timur Tabi]

On Mon, Apr 20, 2015 at 3:31 PM, Scott Wood <scottwood@freescale.com> 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.

Re: new way of writing defconfigs for freescale's powerpc platforms

[Scott Wood]

On Mon, 2015-04-20 at 21:02 -0500, Timur Tabi wrote:
> On Mon, Apr 20, 2015 at 3:31 PM, Scott Wood <scottwood@freescale.com> 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 <foo>.config".

-Scott

Re: new way of writing defconfigs for freescale's powerpc platforms

[Timur Tabi]

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 <foo>.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.

Re: new way of writing defconfigs for freescale's powerpc platforms

[Scott Wood]

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 <foo>.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

Re: new way of writing defconfigs for freescale's powerpc platforms

[Timur Tabi]

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.

Re: new way of writing defconfigs for freescale's powerpc platforms

[Scott Wood]

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

Re: new way of writing defconfigs for freescale's powerpc platforms

[Timur Tabi]

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?

Re: new way of writing defconfigs for freescale's powerpc platforms

[Scott Wood]

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

Re: new way of writing defconfigs for freescale's powerpc platforms

[Michael Ellerman]

On Mon, 2015-04-20 at 21:02 -0500, Timur Tabi wrote:
> On Mon, Apr 20, 2015 at 3:31 PM, Scott Wood <scottwood@freescale.com> 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