[poky] [PATCH 0/1] Add meta-crownbay

Wed Dec 8 22:55:24 PST 2010

On Thu, Dec 9, 2010 at 1:09 AM, Tom Zanussi <tom.zanussi at intel.com> wrote:
> On Wed, 2010-12-08 at 09:52 -0800, Darren Hart wrote:
>> On 12/06/2010 10:39 PM, Tom Zanussi wrote:
>> > Adds a new layer for Tunnel Creek/Topcliff systems.
>> >
>>
>> I'm concerned about the long-term sustainability of this approach of
>> adding a new layer for each "platform". Just Intel platforms alone will
>> make 'ls meta-*' unwieldy in fairly short order, add to that the other
>> architectures and we're looking at a lot of layers.
>>
>> We support a lot of platforms under the existing machine types. Is the
>> primary reason for this being a layer to accomodate the EMGD bits? if
>> so, are those specific to crownbay, or can they somehow be shared across
>> multiple platforms?
>>
>
> Yes, like meta-emenlow, it's a layer mainly because of the special needs
> of the graphics hardware, and yes, there may be other platforms that
> could share the EMGD 1.5 bits - my assumption would be that any common
> factoring for sharing would happen when a second user came along...
>
> But anyway, you hit on a good point, that simply adding new meta-<bsp>
> layers to the top-level could become unwieldy after awhile.  It seems to
> me that that problem could be easily solved by arranging them in a
> directory hierarchy, arranged by TARGET_ARCH, e.g.
>
> /meta-bsp/i586/meta-emenlow
>              /meta-crownbay
>
> (the meta- in front of emenlow, crownbay is redundant, but there just to
> make it clear that the same layers are just being moved around).
>
> And rather than moving away from layers, why not go even further and
> take the existing machine confs, put each into its own layer too:
>
> /meta-bsp/i586/meta-emenlow
>              /meta-crownbay
>              /atom-pc
>              ...
>
> /meta-bsp/arm/beagleboard
>             /cm-x270
>             /depicture
>             ...
>
> /meta-bsp/arm/routerstationpro
>             ...
>
> /meta-bsp/arm/mpc8315e-rdb
>             ...
>
> Each directory (layer) would at least have its machine.conf and its
> associate formfactor, which is currently also in a separate location, so
> it wouldn't be just a directory containing a single file.  This would
> also be a nice place for a board-specific README, so we could get rid of
> things like a global README.hardware and put the README info in that
> file into the directory for the specific board.
>
> It seem to me something like this would be a nice unification of all the
> current 'BSP' support in poky, and would also get rid of the confusion I
> know people have when it comes to deciding whether to use a layer or
> just add a new machine conf - everything would be a layer so there's
> nothing to think about.  And you'd see all the BSPs 'at-a-glance' -
> everything would be located in the same place under a single /bsp (or
> whatever sounds right) location.
>
> Another advantage of this scheme would be that since each BSP would be
> implemented as its own layer within its own directory structure, each
> layer could be easily packaged as a stand-alone tarball or git repo that
> we could then make available here:

For what it is worth, this layering, grouping and flexibility it
provides is the approach we are using at the moment and
it works well. Having the single 'bsp' containing directory
makes all the difference.

It is then trivial to couple packages and special configuration
to any BSP.

>
> http://www.yoctoproject.org/download/board-support-package-bsp-downloads
>
> The Black Sand BSP that's the example there currently can't be
> downloaded as a separate tarball or git repo - you have to download the
> entire yocto release that contains the Black Sand BSP to get it.  Some
> developers might not want to start with a new release, they're already
> using their own modified version, they just want to download support for
> a specific BSP.  To do that for a current non-layer machine, they'd have
> to download the release containing the new machine support, and move the
> applicable files from the release to their own working version.  Having
> it packaged as a modular unit would make things much easier. (BTW all
> the text on that page about how to set up the Black Sand once it's build
> would fit nicely into the atom-pc layer's README).
>
> I think this scheme also more closely matches what Bruce has been trying
> to do for the kernel...

It does match pretty well, yes :)

>
> But anyway, I'm thinking that this plus making the internal structure of
> the current BSPs match what's in the BSP Developer's Guide (either by
> changing the internal structure of the existing layers (and following it
> for the new/converted ones), or changing the doc to how we decide it
> should be) would be a good (and necessary) step towards making BSP
> development for Yocto relatively painless and less confusing.
>
> I know this is probably exactly the opposite of what you were thinking,
> but it seems to me to have a lot of advantages, and I don't see much
> downside, unless I'm missing something.  What do you think?

I think its a good approach, and there's no reason why the two
approaches (many files in the single machine directory) can't
be coupled to the layers .. some layers can always have multiple,
similar BSPs, some wont.

I'm very familiar with this discussion, since I've had the very same
one in the past and we ended up with what you are suggesting Tom.

Cheers,

Bruce

>
> Tom
>
>> For instance, could the xf86 patches be appended to the existing xf86
>> recipe using the SRC_URI_crownbay mechanism?
>>
>> --
>> Darren
>>
>> > Pull URL: git://git.pokylinux.org/poky-contrib.git
>> >    Branch: tzanussi/crownbay
>> >    Browse: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=tzanussi/crownbay
>> >
>> > Thanks,
>> >      Tom Zanussi<tom.zanussi at intel.com>
>> > ---
>> >
>> >
>> > Tom Zanussi (1):
>> >    meta-crownbay: new layer for E6xx/EG20T systems
>> >
>> >   meta-crownbay/COPYING.MIT                          |   17 +++
>> >   meta-crownbay/README.before.building               |  112 ++++++++++++++++++++
>> >   meta-crownbay/conf/layer.conf                      |   10 ++
>> >   meta-crownbay/conf/machine/crownbay.conf           |   46 ++++++++
>> >   .../formfactor/formfactor/crownbay/machconfig      |    3 +
>> >   .../recipes/formfactor/formfactor_0.0.bbappend     |    3 +
>> >   .../recipes/linux/linux-yocto_git.bbappend         |    3 +
>> >   .../xserver-xf86-config/crownbay/xorg.conf         |   47 ++++++++
>> >   .../xorg-xserver/xserver-xf86-config_0.1.bbappend  |    3 +
>> >   .../xorg-xserver/xserver-xf86-emgd-bin_1.7.99.2.bb |   90 ++++++++++++++++
>> >   .../xserver-xf86-emgd/crosscompile.patch           |   19 ++++
>> >   .../fix_open_max_preprocessor_error.patch          |   13 +++
>> >   .../xserver-xf86-emgd/macro_tweak.patch            |   18 +++
>> >   .../xorg-xserver/xserver-xf86-emgd/nodolt.patch    |   12 ++
>> >   .../xorg-xserver/xserver-xf86-emgd_1.7.99.2.bb     |   25 +++++
>> >   15 files changed, 421 insertions(+), 0 deletions(-)
>> >   create mode 100644 meta-crownbay/COPYING.MIT
>> >   create mode 100755 meta-crownbay/README.before.building
>> >   create mode 100644 meta-crownbay/conf/layer.conf
>> >   create mode 100644 meta-crownbay/conf/machine/crownbay.conf
>> >   create mode 100644 meta-crownbay/recipes/formfactor/formfactor/crownbay/machconfig
>> >   create mode 100644 meta-crownbay/recipes/formfactor/formfactor_0.0.bbappend
>> >   create mode 100644 meta-crownbay/recipes/linux/linux-yocto_git.bbappend
>> >   create mode 100644 meta-crownbay/recipes/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
>> >   create mode 100644 meta-crownbay/recipes/xorg-xserver/xserver-xf86-config_0.1.bbappend
>> >   create mode 100644 meta-crownbay/recipes/xorg-xserver/xserver-xf86-emgd-bin_1.7.99.2.bb
>> >   create mode 100644 meta-crownbay/recipes/xorg-xserver/xserver-xf86-emgd/crosscompile.patch
>> >   create mode 100644 meta-crownbay/recipes/xorg-xserver/xserver-xf86-emgd/fix_open_max_preprocessor_error.patch
>> >   create mode 100644 meta-crownbay/recipes/xorg-xserver/xserver-xf86-emgd/macro_tweak.patch
>> >   create mode 100644 meta-crownbay/recipes/xorg-xserver/xserver-xf86-emgd/nodolt.patch
>> >   create mode 100644 meta-crownbay/recipes/xorg-xserver/xserver-xf86-emgd_1.7.99.2.bb
>> >
>> > _______________________________________________
>> > poky mailing list
>> > poky at yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/poky
>>
>>
>
>
> _______________________________________________
> poky mailing list
> poky at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>

-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"