Yocto Layers Clarification Request

[andreacollamati]

Hello,

I have just sync with report the last official yocto fsl bsp release 3.14.28-1.0.0_GA.

I would like to understand better the layer mechanism.

If I run the command:

bitbake-layers show-layers

I get

meta	/data2/yocto/fsl-arm-yocto-bsp/sources/poky/meta  5
meta-yocto	/data2/yocto/fsl-arm-yocto-bsp/sources/poky/meta-yocto  5
meta-oe	/data2/yocto/fsl-arm-yocto-bsp/sources/meta-openembedded/meta-oe  6
meta-multimedia	/data2/yocto/fsl-arm-yocto-bsp/sources/meta-openembedded/meta-multimedia  6
meta-fsl-arm	/data2/yocto/fsl-arm-yocto-bsp/sources/meta-fsl-arm  5
meta-fsl-arm-extra	/data2/yocto/fsl-arm-yocto-bsp/sources/meta-fsl-arm-extra  4
meta-fsl-demos	/data2/yocto/fsl-arm-yocto-bsp/sources/meta-fsl-demos  4
meta-fsl-arm	/data2/yocto/fsl-arm-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-fsl-arm  0
meta-fsl-demos	/data2/yocto/fsl-arm-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-fsl-demos  0
meta-browser	/data2/yocto/fsl-arm-yocto-bsp/sources/meta-browser  7
meta-gnome	/data2/yocto/fsl-arm-yocto-bsp/sources/meta-openembedded/meta-gnome  7
meta-networking	/data2/yocto/fsl-arm-yocto-bsp/sources/meta-openembedded/meta-networking  5
meta-python	/data2/yocto/fsl-arm-yocto-bsp/sources/meta-openembedded/meta-python  7
meta-ruby	/data2/yocto/fsl-arm-yocto-bsp/sources/meta-openembedded/meta-ruby  7
meta-filesystems	/data2/yocto/fsl-arm-yocto-bsp/sources/meta-openembedded/meta-filesystems  6
meta-qt5	/data2/yocto/fsl-arm-yocto-bsp/sources/meta-qt5  7
meta-fsl-qt5	/data2/yocto/fsl-arm-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-fsl-qt5  0
meta-fsl-bluez	/data2/yocto/fsl-arm-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-fsl-bluez  8

So the same layer meta-fsl-arm is splitted over two directories with different priority.

On the other hand, if we look at

• sources/meta-fsl-bsp-release/imx/meta-fsl-arm/conf/layer.conf
• sources/meta-fsl-arm/conf/layer.conf

we have

sources/meta-fsl-bsp-release/imx/meta-fsl-arm/conf/layer.conf

BBFILE_COLLECTIONS += "fsl-bsp-release"

BBFILE_PATTERN_fsl-bsp-release := "^${LAYERDIR}"

BBFILE_PRIORITY_fsl-bsp-release = "8"

sources/meta-fsl-arm/conf/layer.conf

BBFILE_COLLECTIONS += "fsl-arm"

BBFILE_PATTERN_fsl-arm := "^${LAYERDIR}/"

BBFILE_PRIORITY_fsl-arm = "5"

Which one are the correct layer name/priorities?

Thanks in advance.

[daiane_angolini]

The right question is not "which one is the correct one" because none of then are "wrong".

Please, take a look here:

http://freescale.github.io/doc/release-notes/1.7/

And, the exact point you are interested:

FSL Community BSP Release Notes 1.7 documentation

[andreacollamati]

Hi Daiane,

my question was not clear.. sorry.

I was not asking which repositories are the right ones but which are the right priorities and the right names of layers.

The one reported by bitbake-layers command  or the one defined inside layer.conf.

I'm confused about the use of BBFILE_COLLECTIONS variable and BBFILE_PRIORITY inside layer.conf.

The bitbake user manual http://www.yoctoproject.org/docs/1.8/bitbake-user-manual/bitbake-user-manual.html just says:

Maybe is a nonsense question..

If like this just do not respond.

Kind Regards

        Andrea

[daiane_angolini]

The layer "name" is not the layer "path".

So, the layer name is meta-fsl-arm for both different path.

[andreacollamati]

Thanks Diane,

so now the question is why bitbake-layer is reporting priority 0  for /data2/yocto/fsl-arm-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-fsl-arm  and not priority 8.

Digging into the code of bitbake-layer it seems that bitbake is caching priority according to layer name, if layer name is not equal to the collection name the priority is not well reported.

I'm just wondering whether is just a bitbake-layer bug, and we should not be worried about it or the real priority used by bitbake is 0 and not 8 and we should take it into account when we have overlapping recipes.

Thanks

               Andrea

[daiane_angolini]

I really don't understand the question behind your question, so I apologize from now on.

The layer priority is set up on layer.conf file of each meta layer, but only one level of priority is never enough, bitbake also include the order of bblayer.conf file entries. And I would never say there is no bug on bitbake priority resolver, if you really found a bug, there is a bugzilla to record that (I mean, no code should be considered bugless, maybe it is a bug)

In fact, you can change the way layers is copied or used in your system, if this is really important for you. And when the time comes and you need to worry about what is the real priority, maybe it's time for you to reorganize it as you need. You can even fork any of them and change their priority, the question is how better deal with code.

Are you member of #yocto IRC channel or yocto mailing list?

[andreacollamati]

Dear Diane

I found the problem.

All the meta layers included in sources/fsl-bsp-release (meta-fsl-qt5, meta-fsl-bluez,

meta-fsl-arm, meta-fsl-demos) have a layer conf like this:

BBFILE_COLLECTIONS += "fsl-bsp-release"

BBFILE_PATTERN_fsl-bsp-release := "^${LAYERDIR}"

BBFILE_PRIORITY_fsl-bsp-release = "8"

so the COLLECTION key used is the same for all the layers.

So bitbake is not able to evaluate the priority of layer.

This is why  when you issue the command

#>bitbake-layers show-layers

the result is:

meta-fsl-arm      ...../sources/meta-fsl-bsp-release/imx/meta-fsl-arm  0

and not

meta-fsl-arm      ...../sources/meta-fsl-bsp-release/imx/meta-fsl-arm  8

After I changed the layer.conf of each layer directory with a unique name the problem disappeared.

Attention this is not only a "visualization" problem of bitbake-layers command.

I verified that the real priority evaluated by bitbake for the layer meta-fsl-bsp-release/imx/meta-fsl-arm was 0.

I made this test.

I copy the recipe poky/meta/recipes-connectivity/telepathy/libtelepathy_0.3.3.bb (this layer has priority 5) inside the meta-fsl-bsp-release/imx/meta-fsl-arm/ (layer that should have priority 8).

I compiled the package after having refreshed the bitbake cache. The recipe chosen by bitbake was the one in poky/meta/recipes-connectivity and not the one in meta-fsl-bsp-release/imx/meta-fsl-arm.

Then I changed the COLLECTIONS key in order that every layer.conf has a unique key.

I made the test again.

The recipe chosen was the one inside meta-fsl-bsp-release/imx/meta-fsl-arm/.

I hope you can understand my explanation.

Kind Regards

              Andrea

[daiane_angolini]

Yes, I understand. Thanks a lot.

:smileywink:

[gusarambula]

Thank you for the help, Daiane!

I would also recommend the following document which shows the different layers of the Community BSP and BSP Release and may also be of help.

YOCTO PROJECT LAYERS MIND MAP