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.
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
- create default
bitbakesettings (machine, distro etc.),
- launch minimal build environment, reducing the risk of host contamination
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.
According to the kas usage documentation, it can be installed natively via
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 actually two containers available:
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
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
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.
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
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
MACHINE and DISTRO
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:
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.
This mode can certainly be useful for debugging (both issues with our
Below command will make sure that the repositories specified in the
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
target reference in the
kas configuration file.
The build output log looks like:
Note the warning at the top of the log output. Despite using the
aufs as the
storage driver for
wic image built well on my setup. The
explanation of the warning can be found in
this kas commit
My host setup was:
When fetching from private repositories is needed (either during the layers
fetching or during the build process itself), we need to expose access keys
SSH keys) somehow. It seems that the preferred way (at least when
kas-docker) is to use the
-ssh-dir switch of the script:
The contents of the
~/ssh-keys can look like:
After some initial work with the kas, it seems like a great tool for managing
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.