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

Graeme Gregory dp at xora.org.uk
Thu Oct 21 10:04:59 UTC 2010


On 21/10/2010 10:59, Koen Kooi wrote:
> On 21-10-10 11:52, Graeme Gregory wrote:
> > On 21/10/2010 10:33, Koen Kooi wrote:
> >> 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
> >> * recipes/linux/*.inc
> >>
> >> 1 bblayer per machine or SOC_FAMILY containing:
> >> * machine.conf
> >> * first and second stage bootloaders
> >> * kernel
> >>
> >> 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
> > This is something I have advocated before but never formally presented a
> > RFC to OEDEM.
>
> > With this model it quickly becomes clear which machines have support.
>
> > The only problem comes with BLAH_machine type overides. Are they done as
> > amend.inc (or whatever the current method is) in overlay or are they
> > allowed into main repo. I think amend.inc in this case is probably the
> > way to go.
>
> The downside of amend.inc is the de-sync when the recipe gets updated,
> but not the overlay. You run the risk of using a version without the
> overrides that way.
> Maybe some fancy scripts, (pre-)commit hooks or just old fanishioned
> review on the ml could solve those type of issues.
>
> How do file overrides like
> recipes/netbase/netbase/beagleboard/interfaces get handled in a
> bblayer/amend.inc world?
>
Such a pity git doesnt have increasing rev numbers, a cool adition would
be a flag in layer that showed the last rev of core it was tested with.

Layer was tested with core 1 but core is now 999 would give an
indication on drift between layers and core.

Graeme





More information about the Openembedded-devel mailing list