On 07/27/11 10:23, Richard Purdie wrote:
On Wed, 2011-07-27 at 08:55 -0500, Kumar Gala wrote:
Hi Kumar,
As you know, I've been working on several kernel efforts
around the FSL parts as well (in particular the ones that
have enough pieces upstream to work out of the box). I
definitely don't want to overlap in a way that doesn't
create complimentary efforts.
What are your current thoughts around kernels and the
(nearly religious) kernel version question ? It would be
great to get some alignment on features (-rt, tracing,
boot, footprint reduction, etc, etc) and save some effort
on maintenance and validation. Also if we want to create
some yocto reference BSPs, having a kernel version and feature
set match is important as well (i.e. what we've done for
the intel ones).
To that end, do you have an thoughts about using linux-yocto
as a base to any BSP work ? That statement doesn't do it
justice though, since when I say 'use linux-yocto as a base',
it really means that linux-yocto uses your BSPs as an
upstream/official reference and can pull support for them
into branches, and have the configuration and other tooling
get them any functionality that is being developed.
No control over BSP content, or anything like this, is being
suggested or asserted here. Just looking to all push in the
same direction (embedded features and BSPs to upstream) and
re-use the work of BSPs available in the community. If the
base is the same (and hence kernel version), then this relationship
and workflow is very simple.
... and as a bonus, if the workflow doesn't work easily, then
there's a problem with it and we can work on something that
is suitable (change tools, etc).
Thanks,
Bruce
What I'm envisioning as a start is we'd offer a meta layer on yocto
sites for the upstream supported boards& feature set.
I'm still looking at what we do for a FSL delivered BSP (via
freescale.com) that would be based on that. My initial concerns are
that the yocto community will probably move and change things too
frequently for our customer base (kernel version, toolchain version,
etc). Thus my thinking of de-coupling the two a bit. The yocto
versions of BSPs would track yocto development. The FSL delivered
BSPs would probably track to an older yocto version& slower update
cycle.
Just for reference, this is exactly what meta-intel intends to do. The
released versions of the code there are based on a specific release of
Yocto/OE-Core. When new BSPs are developed they are likely developed on
the last stable release of Yocto, not bleeding edge master unless there
is some pressing reason to do so.
Most definitely. Having some sort of alignment on the
kernel versions is nice, but we definitely don't expect
all BSPs to follow every new kernel.
And like Richard said, the model you are thinking about
makes a lot of sense.
If we nominate some important BSPs (one of my post 1.1 tasks),
and they get into the yocto-kernel tree, you have the
advantage that when I uprev the kernel they largely get hauled
along for the ride.
Cheers,
Brice
This is where we start to see major benefits of the layer model.
Cheers,
Richard
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
