Introduction

If you are using the Yocto Project, you certainly have encountered the hassle of managing multiple layers and tracking their revisions.

I’ve been using the Yocto Project for nearly 3 years by now and have mostly been using the tool for this purpose. While I’m not a huge fan of it, it is relatively simple to use and gets the job of fetching layers and controlling their revisions done properly.

The only alternative I knew so far was the combo-layer, although it’s feature set was not enough for me to give up on repo and switch over.

Using kas with Yocto Project

According to the git history, the first public release of the project was at the Jun 14, 2017. I haven’t heard much about it. From my perspective, it gained some traction a couple of months ago – I’ve been seeing some mentions of the kas tool here and there on the various Yocto Project related mailing lists since then.

It seems to be a little bit more than just a tool for fetching and checking out a set of layers to given revisions. The feature set covers:

  • clone and checkout bitbake layers,
  • create default bitbake settings (machine, distro etc.),
  • launch minimal build environment, reducing the risk of host contamination (docker container),
  • initiate bitbake build process.

kas yocto

So far, we’ve mostly been doing the above with a mixture of the repo, our yocto-docker container and a set of shell scripts to automate things. It seems most of it can already be achieved using kas, as it has been developed specifically for managing and configuring the bitbake based projects.

Installation

According to the kas usage documentation, it can be installed natively via pip (python3 is required) or can be run inside docker container. I prefer the latter whenever possible, so I’m going to start with this one.

There are two containers available actually:

Although in this case we are interested in the kasproject/kas container, I am happy to see the kasproject/kas-isar to be present, as we already have some use-cases for the isar project as well.

Although not mentioned in the usage documentation, it is advised to use the kas via the kas-docker script. For convenience, I’m placing it in my ~/bin directory, so it is available in the PATH:

kas configuration

The kas file syntax and the project configuration process is nicely described int the kas project configuration documentation.

An even better way of understanding it may be to take a look at some real examples. I can advise taking a look at the kas.yml from the meta-iot2000.

Transition from repo manifest to kas file

As mentioned earlier, I’ve been using repo to manage the layers and some sample configuration files and a set of shell scripts to manage the build configurations. In the case of kas, all of it can be included in a single kas file.

Yocto Layers in repo manifest

The repo manifest contains a list of layers to fetch and their revisions. For example:

Additionally, we needed an example bblayers.conf file or some kind of shell script to enable the layers we need and adjust the paths to given build environment.

Yocto Layers in kas file

The equivalent excerpt from the kas file would look like:

Note that it not only tells which repositories to fetch and which revisions to use. Based on the above information, kas will also automatically generate the bblayers.conf file with the required layers enabled there.

meta-rte Yocto layers

Transition from shell scripts to kas file

Build configuration in sample files and shell scripts

It is quite a common practice to ship some kind of sane, example build config file (i.e. local.conf file) when providing the Yocto BSP. Sometimes, when some conditional logic is necessary, shell scripts are being incorporated to modify the configuration files based on the user input.

Build configuration in kas file

All configurations can be maintained in a single kas file. In more complicated examples, it can be maintained in a set of kas files by using the include feature.

bblayers.conf

This will be at the top of the bblayers.conf file. Refer to the kas project configuration documentation for _header directive explanation.

local.conf

This will be at the top of the local.conf file. Refer to the kas project configuration documentation for _header directive explanation.

MACHINE and DISTRO

As you probably know, it is essential to set the set the MACHINE and DISTRO. In kas file it is as simple as that:

target

This is the default recipe which will be built during the kas build action. Usually, it will be the main image of our BSP. For example:

Usage

It seems that when using docker container, we have two modes of operation:

  • build the target image with a single command,
  • enter system shell and work directly from there.

Shell

This mode can certainly be useful for debugging (both issues with our Yocto build and kas configuration).

Below command will make sure that the repositories specified in the kas file are properly fetched and checked out. Then it will give us access to the container’s system shell.

I’m using the zsh and faced below error:

It seems that the kas-docker script respects our SHELL environment variable. This can be easily overridden with:

Build Yocto image with kas

The default build can be performed with below command. It will fetch the required layers, make sure they have desired revisions, modify the configuration files accordingly and execute the bitbake task to build the recipe specified by the target reference in the kas configuration file.

The build output log looks like:

asciicast

Note the warning at the top of the log output. Despite using the aufs as the storage driver for docker, the wic image built well on my setup. The explanation of the warning can be found in this kas commit

My host setup was:

Private repositories

When fetching from private repositories is needed (either during the layers fetching or during the build process itself), we need to expose access keys (usually SSH keys) somehow. It seems that the preferred way (at least when using the kas-docker) is to use the -ssh-dir switch of the script:

The contents of the ~/ssh-keys can look like:

And the ~/ssh-keys/config file:

Final example

The final kas file for meta-rte can be found in the meta-rte repository. The documentation on how to build the system for the rte using kas can be found in the meta-rte README.

Conclusion

After some initial work with the kas, it seems like a great tool for managing bitbake based BSP. It seems that it is capable of replacing most of our legacy way of managing bitbake layers and configuration.

In my opinion, the kas project definitely deserves some more popularity. At the moment it has less than 30 stars on github. I can’t wait to see how it would fit in some more complex use-cases we have.

References