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

[Khem Raj]

On Tue, Nov 2, 2010 at 1:46 PM, Koen Kooi <k.kooi at student.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02-11-10 08:02, Frans Meulenbroeks wrote:
>> 2010/10/21 Koen Kooi <k.kooi at student.utwente.nl>:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Hi,
>>>
>>> Recipes/linux is a mess and recipes/u-boot is as well. It would be a
>>> nice topic for OEDEM to see if we discuss switching to a poky BSP model.
>>> It would boil down to:
>>>
>>> 1 base bblayer with shared files:
>>> * conf/machine/include

I think cortexa8 would be  common to non omap/beagleboard machines so
it would be desirable
that this is not overridden from core layer if possible.

>>> * recipes/linux/*.inc

some incs like linux.inc could still stay in core layer

>>>
>>> 1 bblayer per machine or SOC_FAMILY containing:
>>> * machine.conf
>>> * first and second stage bootloaders
>>> * kernel

this is fine. I think SOC_FAMILY or for subarch family is a processor based call
but omap is quite prevalent and has many machines so soc_family in
omap case makes
sense

in general we should try to move minimal stuff into machine layers for
obvious maintenance
burdening reasons. I am afraid that this has potential of leading us
into maintenance problems
if we hold this loosely.

>>>
>>> So, what are peoples thoughts on this? I haven't thought this through
>>> myself, so feel free to point out any show stoppers.
>>> I do not want this to turn into a "splitting the metadata" discussion,
>>> while I'm all for that, it really is a seperate effort and discussion.
>>> But any bblayer style split would benefit from OE being a collection of
>>> git submodules instead of a monolithic tree[1].
>>>
>>> Regards,
>>>
>>> Koen
>>>
>>> [1] Provided git submodules stop sucking so hard in future git versions
>>
>> Replying on the original message on purpose.
>>
>> Is the discussion concluded?
>> How do we proceed with this? Should we have a vote? escalate to TSC?
>> postpone until after the dec 1 release? already do something in a
>> branch?
>
> I have an experimental beagleboard layer, but I want to spend a bit more
> time using it before I come up with an RFC for it.
>
> You have have a look at it at
> http://gitorious.org/angstrom/angstrom-layers/trees/master/BSP/beagleboard
> but I want to stress that it currently is a quick hack that doesn't
> exploit bblayers fully yet.
>
> RP did show me a neat trick to overlay files without copying the
> complete metadata:
>
> http://gitorious.org/angstrom/angstrom-layers/commit/9890faee0eb861bdfd995910090126a8fe83be90.patch
>
> So I would encourage people to try creating their own machine layers to
> get a feel for it so the discussion will be based on actual experience
> instead of handwaving :)
>
> I do fear that pulling things into seperate layers too much will make it
> harder to propagate fixes...
>
> regards,
>
> Koen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Darwin)
>
> iD8DBQFM0HihMkyGM64RGpERAtlXAKCFK7WmZFTQACKJiegOSKx+panfcQCeJpq0
> Iotf629VoDn0Tb48DkbyHkw=
> =ot/l
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>