Frans Meulenbroeks wrote:
2010/11/3 Tom Rini <[email protected]>:
Frans Meulenbroeks wrote:
2010/11/2 Tom Rini <[email protected]>:
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.
I'd say it is definitely nice to have a arch specific overlay (e.g.
ARM, MIPS, PPC, Nios2) which contains the specific recipes for that
architecture.
To give an example:
For nios2 the only backend is for gcc 4.1.2 and binutils
17.50.something. I can imagine that at some point in time it is
decided not to support these in the mainline/standard/common/base
system. In such a case I think the arch specific overlay would be a
good place.
I would argue that so long as someone is maintaining nios2 that means we
can't drop gcc 4.1.2 until there's another stable version for it. And
having that in the nios2 overlay means that it might well start to miss
generic fixes, if we aren't careful.
Don't get me wrong, I'm quite in favor of breaking things up, and putting on
my Mentor hat, we have machine specific overlays and like it.
I understand you. Problem is that I have been peeking into moving
nios2 forward, but the changes in the back end structure between 4.1
and 4.5 are not really minimal, and while I have a basic understanding
on compiler internals, I'm by no means a gcc wiz. So guess 4.1.2 for
nios will be around for quite a while.
And yes, I prefer to keep it on the mainline. as long as possible.
Actually I was mostly using this as an example (because I know this one best).
Whether there should be an omap3 specific overlay (or wheter it should
be cortexA8, or maybe cortexA8 and omap3) remains probably to be seen.
I would suggest initially storing these in the arm machine overlay. If
that one becomes too crowded we alwasy can create an additional layer.
I'm wary of getting too many overlays involved to describe rather simple
cases. An SOC_FAMILY makes sense as an overlay as multiple boards will use
it but not all boards of that overall cpu architecture will.
True. I have no strong feelings in favour or against a soc family layer.
The thing that worries me is that we get too many very small layers.
If there is little content in the soc layer, I would not mind getting
that in the ARM layer (in this case).
If needed we can always split it up.
So we're in agreement, good :)
We might also want to peek at how the kernel arch dir and/or the
u-boot arch dir are organized.
Some arches are done better than others, of course...
--
Tom Rini
Mentor Graphics Corporation
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
