Thanks for the kind words, Nikolay. We are trying to respond more
quickly.
Ann Thornton
On 6/18/2015 10:32 AM, Nikolay Dimitrov wrote:
Hi
Daiane, Otavio,
On 06/18/2015 04:58 PM, Otavio Salvador wrote:
On Thu, Jun 18, 2015 at 10:40 AM, Daiane
Angolini
<daiane.list@gmail.com> wrote:
On Wed, Jun 17, 2015 at 4:45 PM, Otavio
Salvador
<otavio@ossystems.com.br> wrote:
On Wed, Jun 17, 2015 at 4:25 PM,
Nikolay Dimitrov
<picmaster@mail.bg> wrote:
So, in terms of functionality this
kernel sits somewhere
between mainline and FSL releases, is that correct?
Yes; it is FSL release + stable releases + vendor/community
fixes
I've been thinking about this issue. And this provider (for
imx6
only) may make sense to have "fslc" sufix, exactly because it
has
freescale + community patches
However, the other (currently linux-fslc) does not make sense.
Maybe linux-cmt makes more sense today.
I remember one of the arguments to not use only "linux" and
use a
prefix was that it's not a pure mainline provider (it clones
from
github) and because it leave the "linux" only for internal
kernels
Any other suggestion?
I think we need to consider some things here:
linux-fslc is a kernel tree we maintain u-boot-fslc is a u-boot
tree
we maintain
both have same goals and the idea is to provide a place to share
patches and backports.
The motivation to make the 3.14 is because FSL is not taking the
fixes and security updates from stable, so a place to merge
those
seems to be beneficial. I don't want a plethora of names as it
makes
harder for people to contribute and share work so I propose two
solutions:
linux-fslc_4.0.bb linux-fslc-mx6_3.14-1.0.x.bb
or
linux-fslc_4.0.bb linux-fslc_3.14-1.0.x-mx6.bb
Both works.
Thanks for sharing your ideas, this helps me to understand
somewhat
better the motivation behind creating these linux kernel
providers.
So, my comments are not to oppose any changes/improvements at all,
but
just to add a more global perspective on where the Yocto kernel
providers fit in the long chain between mainline and the OEM:
1. linux-mainline
-----------------
Good generic imx6 support, no support for ASRC, VPU. Regarding the
GPU -
Jon Nettleton is working on the etnaviv code, so probably some day
we'll
have a fully open GPU support there. Until then - no GPU support
in
mainline, only basic FB on hdmi/lvds (parallel lcd probably also
works,
but I haven't tested it). Supported by the kernel developers.
2. linux-fslc
-------------
Almost mainline. Here we collect patches that either will take
very long
to be applied in mainline, or are inappropriate for mainline (but
still
useful for Yocto users). As stability and features should be as
good
mainline, if not slightly better due to custom fixes for Yocto.
Supported by Yocto community.
3. linux-as-proposed-by-otavio
------------------------------
Man-in-the middle. Forward-ported FSL code, back-ported important
patches from mainline. Probably something like "linux-imx-next".
Who
will support this code?
4. linux-imx
------------
THE FSL kernel. Freescale's team is doing a great job, and there
are
more or less regular releases with good overall quality. It's
quite
normal/expected that this kernel version will always lag behind
mainline. One thing which bothers me is that there's no way for
the
community to interact with the FSL BSP team, which means no
transparent
way to submit/track/resolve issues. This same role is currently
being
played by the Yocto community due to several individuals who have
internal access to the FSL BSP team and can help pushing through
issues.
Supported by Yocto community (including FSL engineers).
So, even if I like the idea that #3 will have newer code than #4,
the
main question is who will support it (support means both
development and
validation)?
Regards,
Nikolay