[meta-freescale] Please review the proposal of FSL Yocto layers reorg - updated version on 28-Feb

[Otavio Salvador]

On Thu, Feb 28, 2013 at 4:37 PM, McClintock Matthew-B29882
<B29882 at freescale.com> wrote:
> On Thu, Feb 28, 2013 at 1:20 PM, Otavio Salvador
> <otavio at ossystems.com.br> wrote:
>> On Thu, Feb 28, 2013 at 4:17 PM, McClintock Matthew-B29882
>> <B29882 at freescale.com> wrote:
>>> On Thu, Feb 28, 2013 at 6:10 AM, Otavio Salvador
>>> <otavio at ossystems.com.br> wrote:
>>>> On Thu, Feb 28, 2013 at 3:16 AM, Luo Zhenhua-B19537
>>>> <B19537 at freescale.com> wrote:
>>>>> Hello all,
>>>>>
>>>>> Thanks a lot for the comments.
>>>>>
>>>>> I did some update according to the feedback and removed some bits of internal activity. Please review and comment.
>>>>
>>>> From the update, I think it is much more inline with I believe it'd be
>>>> the best way of doing it. Personally I found two things which could be
>>>> further discussed:
>>>>
>>>> * meta-fsl-layerscale:
>>>>
>>>>   As Vybrid it could have the BSP part inside meta-fsl-arm and
>>>> meta-fsl-ppc; I think the not BSP parts could go to
>>>> meta-fsl-networking or similar and keep the BSP part unified. This
>>>> would make easier for users and also make it easier for vendors to
>>>> make customized BSPs using this as a common base.
>>>
>>> I think layerscape and vybrid recipes should go in their own
>>> SDK/distro layers (what does not belong in meta-fsl-{ppc,arm})
>>
>> From my point of view, BSP could go to meta-fsl-{ppc,arm} and
>> networking/multimedia go to the respective layers.
>
> Right, board support should in in the meta-fsl-{ppc,arm} and extra
> recipes/support in the networking/multimedia layers
>
>>>> * meta-freescale-sdk:
>>>>
>>>>   It is not clear from the description what it would have inside. If
>>>> it are going to have poky and all other layers the name is misleading.
>>>> freescale-sdk or freescale-yocto-sdk would be better. Could you
>>>> clarify it?
>>>
>>> I like the idea of meta-freescale-yocto-sdk since we are based on that.
>>
>> It all depends if it will provide poky or not. If it does, meta prefix
>> ought to be dropped. meta prefix is used for layers and not complete
>> SDKs so it will be confusing.
>
> We have used poky in the past on the ppc side, what are you thoughts here?

It all depends on what Freescale wants to offer to the customers. I
see the possible options:

 1) reference SDK

    mostly as done by fsl-community-bsp however with meta-fsl-ppc,
meta-fsl-multimedia and meta-fsl-networking all enabled and without
meta-fsl-arm-extra since the reference SDK should support just the FSL
official boards. This should use Poky and meta-openembedded from
git.yoctoproject.org and meta git.openembedded.org and have just what
is possible to provide without forking those projects.

 2) meta-freescale

    A repository which merges other layers (meta-fsl-*). So users to
use it would need to clone others as Poky and meta-openembedded for
allow the use of it.

 3) full supported SDK

   A full supported SDK which might be done as fsl-community-bsp
however which uses forks of Poky / meta-openembedded with not merged
stuff.

Personally I don't like option number 2 as it just confuse users in my
point of view.

I'd go with option number 1 as it reduces the amount of code which FSL
needs to support and allow more reuse of work. I understand sometimes
it will slow down things as some changes/improvements might be blocked
by release schedule of Yocto but it still seems like the natural
choice for me.

The option number 3 seems over complicating things as it will be
forcing FSL to maintain a fork of stuff and it has several
implications (QA, security, documentation and so on).

Those are the options *I* see; someone might see other alternatives as
well. In any case, it is important to understand how FSL intend to
work in this point as each option has pros and cons.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br