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
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
