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

[Tom Rini <tom_rini@mentor.com>]

Frans Meulenbroeks wrote:
> 2010/11/3 Tom Rini <tom_rini@mentor.com>:
>> Frans Meulenbroeks wrote:
>>> 2010/11/2 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.
>>>>
>>> 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