On Tue, Nov 2, 2010 at 1:46 PM, Koen Kooi <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 02-11-10 08:02, Frans Meulenbroeks wrote: >> 2010/10/21 Koen Kooi <[email protected]>: >>> -----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 > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
