[meta-freescale] Please review the proposal of FSL Yocto layers reorg

Otavio Salvador otavio at ossystems.com.br
Wed Feb 27 04:09:02 PST 2013


On Wed, Feb 27, 2013 at 3:57 AM, Luo Zhenhua-B19537
<B19537 at freescale.com> wrote:
>> -----Original Message-----
>> From: otavio.salvador at gmail.com [mailto:otavio.salvador at gmail.com] On
>> Behalf Of Otavio Salvador
>> Sent: Wednesday, February 27, 2013 5:44 AM
>>
>> > 2) I still don't really see the point in renaming from meta-fsl-ppc ->
>> > meta-fsl-qoriq as well as meta-fsl-arm to meta-fsl-imx. But, I wonder
>> > what others think about this. It seems like unneeded changes that will
>> > just cause confusion. Why not just put vybird in meta-fsl-arm?
>>
>> I support this idea and it'd make users' life much easier.
> [Luo Zhenhua-B19537] One reason is, if meta-fsl-arm is used, the i.MX targets and Layerscape arm targets are maintained in the same layer, this might confuse users, E.g. LS arm machines are visible to users of i.MX multimedia SDK. Same for PPC targets.
>         i.MX guys, any other reason for the renaming?

Not necessarially; personally I think users will like to have to worry
about less layers. It even facilitates the reuse of code and make
documentation easier. From my point of view, meta-fsl-arm and
meta-fsl-ppc could be the two BSP layers and others could be add
around (meta-fsl-networking, meta-fsl-multimedia, ...) in
git.freescale.com for extra images and demo recipes.

>> > 3) I think we should delay the creation of some of these layers until
>> > we really have packages that are duplicated between two layers (e.g.
>> > meta-layerscape can wait until we have a recipe that is needed for
>> > both ARM and PPC and is not upstream in another layer)
>>
>> Personally I think it won't happen often as usually it'll not be a BSP
>> package that will fit in this set so it'll end in meta-virtualization or
>> meta-networking eventually.
> [Luo Zhenhua-B19537] I agree to delay the creation of some layers till they are necessary. We should upstream those shared packages into oe-core/meta-oe/meta-virtualization/... upstream layers as much as possible.

Good.

>> > 4) I think we need some more info about the "unifed" layer. I don't
>> > think it needs to exist yet, but maybe others would like to see it.
>> > Personally, I think it can be created automatically much like poky is
>> > now.
>>
>> As I said, I fear it adding more confusing than solving. It might making
>> users wonder which layer he/she will use and don't know exactly the
>> difference between the merged layer and the individual ones.
> [Luo Zhenhua-B19537] there may be some confusion, meta-freescale is similar as https://github.com/Freescale/fsl-community-bsp-platform, it can make it easy for users to download the required layers of right version for a specific FSL SDK. This layer is SDK specific and only maintained in Freescale git repository.

But it won't include all needed parts for user so it will only add
confusion. What makes fsl-community-bsp nice is that it does all for
you and gives you a working solution however meta-freescale will give
you a set of layers, only.

-- 
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



More information about the meta-freescale mailing list