From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: William Mills <wmills@ti.com>
Cc: meta-ti@yoctoproject.org
Subject: Re: question on meta-ti for yocto
Date: Thu, 22 Mar 2012 17:34:06 +0000 [thread overview]
Message-ID: <1332437646.9740.276.camel@ted> (raw)
In-Reply-To: <4F6B57CB.5080000@ti.com>
On Thu, 2012-03-22 at 12:48 -0400, William Mills wrote:
> >> Op 21 mrt. 2012, om 23:10 heeft Richard Purdie het volgende geschreven:
> >>> The trouble is Koen keeps doing this and nobody in general replies. The
> >>> lack of a reply can be seen as to condone what was said and its
> >>> certainly leading to people getting more confused. I think a response
> >>> was appropriate.
>
> For the record I will try to speak for the official TI position on this.
Thanks!
> 6) Although we plan to support base oe-core and poky configurations,
> they will *not* be recommended configurations for several reasons:
> 6.1) oe-core and poky ignore ~ 12 month of toolchain improvements made
> by Linaro.
> 6.2) At this time, all of the internal and customer validation of TI
> BSPs has been done with a gcc 4.5 based toolchain that includes the
> linaro patches.
>
> As stated in #6, TI will continue to recommend meta-oe in the layer
> stack to get the toolchain that TI tests with. We hope, as work with
> linaro continues to switch that to an official meta-linaro layer.
I think there could be better integration with Linaro and I know work is
being done in this area so I'm hoping this situation will improve.
I know Bill understands this but just to be clear for the record, the
only scalable way OE-Core can work is to embrace upstream latest
releases as much as is practicable which is why 4.6 is currently used.
If people need something different *and* step up with resources to
maintain/test it, we can talk about other versions but for anything like
an extra toolchain, we need people to help support it.
Just to illistrate this, making a release of OE-Core/Poky currently
involves testing on 5 'architectures' on virtual and real hardware with
about 8 different images to test along with features like sstate,
sdk/toolchain, no-gplv3, multilib and tiny. This gives a staggering test
matrix.
> TI will continue to test with and recommend a toolchain that is closely
> aligned with Linaro. We see no reason customers should have to misalign
> themselves with the ARM ecosystem just to align with poky.
s/poky/upstream/
and with 4.7 (out today), we should have a lot of the Linaro fixes,
right so this problem should start solving itself when we update to
4.7? :)
The layer model should make this less of an issue if we can have a
strong layer containing that toolchain. I know progress is being made in
splitting this from meta-oe so that should simplify the problem.
> ---------------------------------
> [speaking for myself now]
>
> I fully support base poky testing but I think we are getting dangerously
> close to a defacto statement that the only real yocto based distro is
> one that _only_ uses poky + a BSP layer. I am not aligned with that
> view.
FWIW I'm not aligned with that view either!
> I think oe-core and poky are a fine base but many customers will
> need to expand on what is there with more layers.
I think its fine to say poky is the way Yocto tests and validates
OE-Core and is something it can release as a tested know to work base
people can build off. As such, pointing people to poky as a way of
testing and getting started is reasonable.
I also think its fine to say that poky + a BSP layer should work without
anything else.
Its perfectly reasonable for people to add in other layers on top of
that.
> Richard,
>
> You seem to take offense at Koen's claim that Angstrom is Yocto. As I
> stated above I don't think Angstrom _is_ yocto but how do we refer to
> distributions that are based off of oe-core or even poky that include
> other layers.
I'm not sure I took offence, I was just trying to clearly position
things. Poky isn't Yocto either in the strict sense, its a component of
it.
> Are they "Yocto based" or "Yocto aligned"? How about
> "Yocto adjacent" :) ?
That is a good question and I don't have the answer. I think I like
"Yocto aligned" as it implies its sharing the objectives of Yocto,
particularly around layers, OE-COre and BSPs which I believe Angstrom
is.
I'd suggest on this detail, it gets raised with the Yocto AB and
Advocacy people and we should document what "Yocto alignment" means
somewhere.
Cheers,
Richard
next prev parent reply other threads:[~2012-03-22 17:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-21 14:58 question on meta-ti for yocto Marco Monguzzi
2012-03-21 15:14 ` Koen Kooi
2012-03-21 20:42 ` Russell Senior
2012-03-21 20:45 ` Denys Dmytriyenko
2012-03-21 20:48 ` Koen Kooi
2012-03-21 21:27 ` Richard Purdie
2012-03-21 21:45 ` Denys Dmytriyenko
2012-03-21 22:10 ` Richard Purdie
2012-03-22 6:31 ` Koen Kooi
2012-03-22 15:07 ` Denys Dmytriyenko
2012-03-22 16:48 ` William Mills
2012-03-22 17:23 ` Koen Kooi
2012-03-22 19:39 ` Richard Purdie
2012-03-22 17:34 ` Richard Purdie [this message]
2012-03-22 18:28 ` William Mills
2012-03-22 19:14 ` Richard Purdie
2012-03-22 20:25 ` Denys Dmytriyenko
2012-03-22 0:25 ` Philip Balister
2012-03-21 22:12 ` Denys Dmytriyenko
2012-03-22 10:56 ` Marco Monguzzi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1332437646.9740.276.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=meta-ti@yoctoproject.org \
--cc=wmills@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.