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

[Frans Meulenbroeks <fransmeulenbroeks@gmail.com>]

2010/11/3 Khem Raj <raj.khem@gmail.com>:
> On Wed, Nov 3, 2010 at 1:17 PM, Tom Rini <tom_rini@mentor.com> wrote:
>> 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).
>
> I dont think it would make sense to put things like gcc and binutils
> and core components
> into overlays. You stand the risk of out dating these recipes for
> developers it would be more focused
> to make changes for such things in one place. I will not go into every
> overlay and  propagate a gcc change to
> each one of them thats simply waste of time. Because the change to
> core effects all  I urge to
> practice restrain and not do these kind of things. OE can have recipes
> for multiple versions of a given package live together.
> As far as machine specific recipes are considered I think its ok
> although I would suggest to leverage common stuff as much as can be
> done.
>
I'm not planning to.
This would be the solution if for one reason or another gcc 4.1.2 was
kicked from the base layers (or the associated binutils).
I have a very strong preference ot keep them in the base layer.
This was only intended as an example.
Apologies for the misunderstanding and confusion.

FM