Re: [RFC] turning conf/machine into a set of bblayers

[Tom Rini <tom_rini@mentor.com>]

Eric Bénard wrote:
> Hi,
> 
> Le 02/11/2010 21:46, Koen Kooi a écrit :
>> I do fear that pulling things into seperate layers too much will make it
>> harder to propagate fixes...
>>
> yes, in your example, the fines in conf/machine/include are common to 
> all omap boards (and even all cortexa8 for tune-cortexa8.inc) and thus 
> when fixing one BSP you have to think to fix the others (and to 
> communicate the fix to other BSP maintainers).
> The same apply for most of the .inc in recipes-bsp/*/.
> 
> Do you think the following setup is possible ?
> 
> - ARM overlay (containing all generic files for ARM achitecture : 
> conf/machines/include for example)
> 
> - OMAP3 overlay (containing all generic files for OMAP3 SOC : 
> conf/machines/include/omap* + recipes/linux u-boot x-load base files for 
> omap3 architecture,
> 
> - specific board overlay (conf/machine/themachine.conf + board specific 
> additions in recipes/linux u-boot & x-load (with patches based on top of 
> the OMAP3 overlay).

How about:

- allow some form of conf/machine/include to continue to exist in the 
main layer

? There would have to be some judgment calls, but I don't think that 
should be too hard, over when it's SOC_FAMILY or when it's very generic. 
  Basically the ARM overlay wouldn't be created in this case (nor the 
PPC nor MIPS nor ...).  But we must avoid duplicating tune-coretexa8.inc 
and similar.

-- 
Tom Rini
Mentor Graphics Corporation