[oe] [RFC] turning conf/machine into a set of bblayers
Tom Rini
tom_rini at mentor.com
Tue Nov 2 21:21:38 UTC 2010
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
More information about the Openembedded-devel
mailing list