From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 68666E00A31; Thu, 18 Jun 2015 08:32:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (picmaster[at]mail.bg) * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [193.201.172.118 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mx2.mail.bg (mx2.mail.bg [193.201.172.118]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id D36BCE00982 for ; Thu, 18 Jun 2015 08:32:52 -0700 (PDT) Received: from [192.168.0.62] (unknown [93.152.143.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx2.mail.bg (Postfix) with ESMTPSA id A95166000736; Thu, 18 Jun 2015 18:32:49 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1434641569; bh=5a0C5QtDLwNAH0s11HuEhvsfqCmBixKeFnb6Y9ZuLG0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=M8cO3PfHXHny8WxFMP+1odIKH+W6IR8dmedx7GXHIiSmZWP55Wf+uXxurFpa+QLM8 8ewaUOf8pnQsnyo9QChEufHci1Xk3C4nwWV/yUcSpEuDeD86lVuV+yKOS3WjtH5iI9 0BFZl/OVTYXcSx1qJTwjsXWILdUO6rnUdvVONYMs= Message-ID: <5582E4A1.5070108@mail.bg> Date: Thu, 18 Jun 2015 18:32:49 +0300 From: Nikolay Dimitrov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Otavio Salvador , Daiane Angolini References: <1434564146-11377-1-git-send-email-otavio@ossystems.com.br> <1434564146-11377-3-git-send-email-otavio@ossystems.com.br> <5581BC50.5020504@mail.bg> <5581BE95.9060009@mail.bg> <5581C98C.8060802@mail.bg> In-Reply-To: Cc: meta-freescale Mailing List Subject: Re: [meta-fsl-arm][PATCH 3/4] linux-fslc-mx6 (3.14-1.0.x): Add recipe X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 15:32:59 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Daiane, Otavio, On 06/18/2015 04:58 PM, Otavio Salvador wrote: > On Thu, Jun 18, 2015 at 10:40 AM, Daiane Angolini > wrote: >> On Wed, Jun 17, 2015 at 4:45 PM, Otavio Salvador >> wrote: >>> On Wed, Jun 17, 2015 at 4:25 PM, Nikolay Dimitrov >>> 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