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

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

[Koen Kooi]

-----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
* 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMwAjgMkyGM64RGpERAs3LAKCBtFoOPe49JO/K3SlC0euYs8XOCgCeKLsF
UMRKOIhRMMwUgrh5RsQ8dEw=
=nlIb
-----END PGP SIGNATURE-----

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

[Graeme Gregory]

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.

Probably some form of dummy machine (maybe x86) needs to be defined in
main repo just so main repo can be parsed.

Graeme

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

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMwA8OMkyGM64RGpERAlSFAJwMPvcXiGBMWqIspIaG+TLzpohAaQCfVUVy
hWVW4K67s6Drr381HtpIc+w=
=OSYR
-----END PGP SIGNATURE-----

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

[Graeme Gregory]

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

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

[Frans Meulenbroeks]

Some initial thoughts:

What about out-of-tree kernel modules?
No idea right away whether we have many.
I can imagine we want to keep these in one place (I doubt if they are
very machine specific).

putting the recipes in the overlay creates some duplication (and hence
potentially double maintenance).
Probably for kernel this is less of an issue as most machines seem to
have their own kernel.

There is however the case that machines like to share the same kernel.
E.g. sheevaplug/openrd client/openrd base/openrd ultimate (and perhaps
pogoplug and dockstar). These are all based upon the same soc.

The thing I do like less about the amend.inc proposal is that unless
we are very careful and strict with the contents of the linux dir we
still end up with quite some recipes in there.
(you probably end up with a base recipe for every git tree; and maybe
even for different tags in it). this is probably less desirable.

And wrt u-boot there seems to be some more commonality (although the
u-boot_git recipe is quite big).

Maybe someone could craft a usage table (don't have time to do that
right now myself).

More later....

Have fun! Frans

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

[Frans Meulenbroeks]

2010/10/21 Graeme Gregory <dp@xora.org.uk>:

>>
> 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

Triggered by this (and apologies if I am drifting off-topic).
It would be nice if with amend.inc you could specify the PR of the
underlying recipe that this amend is for (and get a warning or error
if there is a mismatch)

Frans.

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

[Richard Purdie]

On Thu, 2010-10-21 at 12:20 +0200, Frans Meulenbroeks wrote:
> 2010/10/21 Graeme Gregory <dp@xora.org.uk>:
> 
> >>
> > 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
> 
> Triggered by this (and apologies if I am drifting off-topic).
> It would be nice if with amend.inc you could specify the PR of the
> underlying recipe that this amend is for (and get a warning or error
> if there is a mismatch)

For reference poky now has the PRINC = "x" variable which increases the
base PR by x, assuming a standard format PR value. This is intended for
use in .bbappend files.

Cheers,

Richard

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

[Frans Meulenbroeks]

2010/10/21 Richard Purdie <rpurdie@rpsys.net>:
> On Thu, 2010-10-21 at 12:20 +0200, Frans Meulenbroeks wrote:
>> 2010/10/21 Graeme Gregory <dp@xora.org.uk>:
>>
>> >>
>> > 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
>>
>> Triggered by this (and apologies if I am drifting off-topic).
>> It would be nice if with amend.inc you could specify the PR of the
>> underlying recipe that this amend is for (and get a warning or error
>> if there is a mismatch)
>
> For reference poky now has the PRINC = "x" variable which increases the
> base PR by x, assuming a standard format PR value. This is intended for
> use in .bbappend files.
>
> Cheers,
>
> Richard
>

Maybe I was not clear enough on this, but my proposal would be that
you could say in your amend file something like
BASEPR_CHECK("r12")
or something like that (I did not really think about what the best
syntax would be).

If you were building and the base recipe did not have the PR you
specified you'd get a warning (or maybe even an error) so you would
know that something changed under water.

Best regards, Frans

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

[Maupin, Chase]

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On Behalf Of
> Frans Meulenbroeks
> Sent: Thursday, October 21, 2010 7:01 AM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [RFC] turning conf/machine into a set of bblayers
> 
> 2010/10/21 Richard Purdie <rpurdie@rpsys.net>:
> > On Thu, 2010-10-21 at 12:20 +0200, Frans Meulenbroeks wrote:
> >> 2010/10/21 Graeme Gregory <dp@xora.org.uk>:
> >>
> >> >>
> >> > 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
> >>
> >> Triggered by this (and apologies if I am drifting off-topic).
> >> It would be nice if with amend.inc you could specify the PR of the
> >> underlying recipe that this amend is for (and get a warning or error
> >> if there is a mismatch)
> >
> > For reference poky now has the PRINC = "x" variable which increases the
> > base PR by x, assuming a standard format PR value. This is intended for
> > use in .bbappend files.
> >
> > Cheers,
> >
> > Richard
> >
> 
> Maybe I was not clear enough on this, but my proposal would be that
> you could say in your amend file something like
> BASEPR_CHECK("r12")
> or something like that (I did not really think about what the best
> syntax would be).
> 
> If you were building and the base recipe did not have the PR you
> specified you'd get a warning (or maybe even an error) so you would
> know that something changed under water.

I haven't tried this myself yet, but if you wanted to tie to a particular PR of the base recipe wouldn't you just put the amend.inc in your overlay at recipes/blah/blah-version-pr directory?

> 
> Best regards, Frans
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

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

[Chris Larson]

On Thu, Oct 21, 2010 at 6:46 AM, Maupin, Chase <chase.maupin@ti.com> wrote:

> I haven't tried this myself yet, but if you wanted to tie to a particular
> PR of the base recipe wouldn't you just put the amend.inc in your overlay at
> recipes/blah/blah-version-pr directory?


Yes, but bbappend can't do that, its bound to the recipe filename,
unfortunately.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

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

[Denys Dmytriyenko]

On Thu, Oct 21, 2010 at 07:21:49AM -0700, Chris Larson wrote:
> On Thu, Oct 21, 2010 at 6:46 AM, Maupin, Chase <chase.maupin@ti.com> wrote:
> 
> > I haven't tried this myself yet, but if you wanted to tie to a particular
> > PR of the base recipe wouldn't you just put the amend.inc in your overlay at
> > recipes/blah/blah-version-pr directory?
> 
> Yes, but bbappend can't do that, its bound to the recipe filename,
> unfortunately.

Right, that's why bbappend is inferior to amend... :)

-- 
Denys

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

[Tom Rini]

Frans Meulenbroeks wrote:
> 2010/10/21 Graeme Gregory <dp@xora.org.uk>:
> 
>> 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
> 
> Triggered by this (and apologies if I am drifting off-topic).
> It would be nice if with amend.inc you could specify the PR of the
> underlying recipe that this amend is for (and get a warning or error
> if there is a mismatch)

I know I'm late to the party but.. I don't think this is a big deal. 
Changes getting out of sync from foopkg 1.1 to foopkg 1.2?  Yes.  foopkg 
1.1 PR="r1" to 1.1 PR="r10" ?   Unlikely and something the human control 
side should be able to handle.

-- 
Tom Rini
Mentor Graphics Corporation

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

[Richard Purdie]

On Thu, 2010-10-21 at 11:59 +0200, Koen Kooi wrote:
> 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?

Taking a poky example of formfactor which is a very similar situation,
create a .bbappend file:

http://git.pokylinux.org/cgit/cgit.cgi/poky/tree/meta-emenlow/packages/formfactor/formfactor_0.0.bbappend

with the contents of:

FILESEXTRAPATHS := "${THISDIR}/${PN}"
PRINC = "1"

and place the appropriate files underneath as usual:

http://git.pokylinux.org/cgit/cgit.cgi/poky/tree/meta-emenlow/packages/formfactor/formfactor/emenlow/machconfig

We should make it a hard fail if a .bbappend is found with no
corresponding .bb file, I'm not sure if that happens or not at the
moment.

I've also been thinking a lot about FILESPATH and have been thinking
that making the list of defaults small and having recipes specify if
they use overrides would be a good idea.

E.g. so above you'd have to specify:

"${THISDIR}/${PN}/${MACHINE}" explicitly.

Cheers,

Richard

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

[Graeme Gregory]

On 21/10/2010 11:48, Richard Purdie wrote:
> On Thu, 2010-10-21 at 11:59 +0200, Koen Kooi wrote:
>> 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?
> Taking a poky example of formfactor which is a very similar situation,
> create a .bbappend file:
>
> http://git.pokylinux.org/cgit/cgit.cgi/poky/tree/meta-emenlow/packages/formfactor/formfactor_0.0.bbappend
>
> with the contents of:
>
> FILESEXTRAPATHS := "${THISDIR}/${PN}"
> PRINC = "1"
>
> and place the appropriate files underneath as usual:
>
> http://git.pokylinux.org/cgit/cgit.cgi/poky/tree/meta-emenlow/packages/formfactor/formfactor/emenlow/machconfig
>
> We should make it a hard fail if a .bbappend is found with no
> corresponding .bb file, I'm not sure if that happens or not at the
> moment.
>
Only half joking, maybe we should RFC just making OE a community bblayer
for poky.

Graeme

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

[Chris Larson]

On Thu, Oct 21, 2010 at 2:59 AM, Koen Kooi <k.kooi@student.utwente.nl>wrote:

> 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?
>

You could adjust FILESPATHBASE in your layer.conf for the machine to include
${LAYER}/recipes/${@os.path.basename(os.path.dirname('${FILE}'))} or
something.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

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

[Richard Purdie]

On Thu, 2010-10-21 at 11:33 +0200, Koen Kooi wrote:
> 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

In addition you'll most likely need some machine config in the form
of .bbappend files for things like base-files, netbase, xorg-config,
formfactor (in Poky's case).

> So, what are peoples thoughts on this? I haven't thought this through
> myself, so feel free to point out any show stoppers.

Poky is certainly heading in this direction and I've worked to ensure we
have all the needed support in the form of .bbappend, the layer.conf
files and so forth. If for whatever reason there are any other
limitations, we should look at fixing that.

> But any bblayer style split would benefit from OE being a collection of
> git submodules instead of a monolithic tree[1].
>
> [1] Provided git submodules stop sucking so hard in future git versions

If they stopped sucking, maybe...

Cheers,

Richard

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

[Frans Meulenbroeks]

2010/10/21 Koen Kooi <k.kooi@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
> * 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

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?

Personally I am in favour of the idea.

Best regards, Frans

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

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02-11-10 08:02, Frans Meulenbroeks wrote:
> 2010/10/21 Koen Kooi <k.kooi@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
>> * 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
> 
> 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-----

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

[Eric Bénard]

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).

Eric

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

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02-11-10 22:14, 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).

That was pretty much what I was thinking, the angstrom-layers stuff is
something I need to get working before thursday, so it is a bit hacky.
It will get cleaned up after I get back from my holiday :) Hopefully
more people have tried different setups and we can bang out a decent RFC.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFM0IBFMkyGM64RGpERAhVvAJ98xHlzrMSjH/d6a5//GQimg89j0wCgnVIs
ASfxeRULybqKbDAjBMlwkXg=
=tE/N
-----END PGP SIGNATURE-----

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

[Tom Rini]

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.

-- 
Tom Rini
Mentor Graphics Corporation

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

[Frans Meulenbroeks]

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.

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.

Khem wrote:
> 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 usinto maintenance problems
> if we hold this loosely.

I fully agree with this.
In my opinion the rule should be:
machine specific stuff should go into the machine overlay. A machine
overlay could cover several closely related machines (e.g.
beagleboard, beagleboard-XM (should these be considered as different)
arch specific stuff (including stuff that is appropriate for multiple
machines in the arch.
non hw specific stuff should go into the common base.

We should definitely avoid that multiple recipes and multiple recipe
variants are created as that creates a maintenance nightmare.

Coming back on the gcc/nios2 example.
I'd expect this to be in the common base, but if at some point in time
it is decided to eliminate it from there, it should move to the nios2
overlay.
Maintenance responsibility then shifts from the maintainers of the
common base to the maintainer of the nios2 layer.

Frans.

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

[Tom Rini]

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.

> 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.

-- 
Tom Rini
Mentor Graphics Corporation

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

[Frans Meulenbroeks]

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.
We might also want to peek at how the kernel arch dir and/or the
u-boot arch dir are organized.

Frans

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

[Tom Rini]

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

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

[Khem Raj]

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.

>>
>>>> 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
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

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

[Frans Meulenbroeks]

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

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

[Khem Raj]

>>
> 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.
>

No recipes that are actively used should ever be deleted.

> FM
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

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

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03-11-10 21:44, Khem Raj wrote:

> I dont think it would make sense to put things like gcc and binutils
> and core components
> into overlays.

I would put those into a 'devtools' layer, like poky has done.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFM0mVjMkyGM64RGpERAspiAKCCVvbm5EWD3OejRvjSCxAxbBEsoQCfVjND
kvkJ8A0aRkuCV5lP28eXLas=
=rw7D
-----END PGP SIGNATURE-----

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

[Khem Raj]

On Tue, Nov 2, 2010 at 1:46 PM, Koen Kooi <k.kooi@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@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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>