fw-kdevops

fw-kdevops is a fork of kdevops, simplified for only testing the Linux kernel firmware API.

Only two target hosts are provisioned:

• fw-stable: tracks the baseline
• fw-dev: let's you test development patches

Upstream documentation

Read the documentation about the Linux kernel firmware API.

Firmware loader kconfig options

We test the firmware loader through the Linux kernel's selftests framework, and selftests lets you declare which kernel configurations are required to test a target subsystem. These are the respective kernel configuration options we enable on our test hosts:

CONFIG_TEST_FIRMWARE=y
CONFIG_FW_LOADER=y
CONFIG_FW_LOADER_USER_HELPER=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y

The code in question we test inside the Linux kernel is what implements the CONFIG_FW_LOADER, so all the code under:

drivers/base/firmware_loader/

The other options just conveniences to let our tests run smoother, and also lets us test all aspects of the firmware API with just one Linux kernel configuration. That is, regardless of what kernel configuration you may have, the above configuration is targetted at testing all possible code for the firmware API.

Install dependencies

You should have installed ansible, vagrant and terraform (hopefully we'll have a local ansinle role to do this eventually). After that, all you have to do is:

make deps

Be sure to read the recommendations on the kdevops about how to let your regular user be able to run qemu. Eventually this should be as easy as optionally running a local ansible role, but for now this requires a bit of manual effort.

Provisioning hosts with vagrant

cd vagrant/
vagrant up

Destroying provisioned nodes with vagrant

You can either destroy directly with vagrant:

cd vagrant/
vagrant destroy -f
# This last step is optional
rm -rf .vagrant

Or you can just use virsh directly, if using KVM:

sudo virsh list --all
sudo virsh destroy name-of-guest
sudo virsh undefine name-of-guest

Terraform support

Read the kdevops_terraform documentation, then come here and read this.

Terraform is used to deploy your solution on cloud virtual machines. Below are the list of clouds currently supported:

• azure
• openstack (special minicloud support added)
• aws

Provisioning with terraform

make deps
cd terraform/you_provider
make deps
terraform init
terraform plan
terraform apply

Because cloud providers can take time to make hosts accessible via ssh, the only thing we strive for is update your ~/ssh/config for you. Once the hosts become available you are required to run ansible yourself.

Terraform ssh config update

We provide support for updating your ssh configuration file (typically ~/.ssh/config) automatically for you, however each cloud provider requires support to be added in order for this to work. Below is the status of support for this by different cloud providers we support:

• OpenStack
• Generic OpenStack solutions
• Minicloud
• Azure: requires work
• AWS: requires work

Running ansible

Before running ansible make sure you can ssh into the hosts listed on ansible/hosts. So try:

ssh fw-dev
ssh fw-stable

Using ansible to install the latest linux-next target

Next to run ansible to install and reboot into the latest linux version this project tracks:

ansible-playbook -i hosts playbooks/bootlinux.yml

Using ansible to run selftests for the firmware API

ansible-playbook -i hosts playbooks/selftests.yml

This is what you are expected to see provided no regressions were found:

Debugging failures

The selftest ansible role does not provide actual output, it just tells you if a failure was found. If a failure was found its time then to ssh into the respective host and run the self test on your own to debug things manually.

Testing a set of patches against the firmware API

You can use a different tag for the kernel revision from the command line, and even add an extra patch to test on top a kernel. Say we're in the future, on September 15, 2022, and you want to test that day's version of linux-next with your hacks implemented on fw-is-cool.patch. You can use:

ansible-playbook -i hosts -l dev --extra-vars "target_linux_version=next-20220915 target_linux_extra_patch=fw-is-cool.patch" playbooks/bootlinux.yml

You would have these files in place as well:

~/.ansible/roles/mcgrof.bootlinux/templates/fw-is-cool.patch
~/.ansible/roles/mcgrof.bootlinux/templates/config-next-20220915

To reboot hosts

Say you just want to reboot the hosts:

ansible-playbook -i hosts playbooks/bootlinux.yml --tags reboot

Public ansible role documentation

The following public roles are used, and so have respective upstream documentation which can be used if one wants to modify how the role runs with additional tags or extra variables from the command line:

• create_partition
• update_ssh_config_vagrant
• devconfig
• bootlinux

Kernel configuration files are tracked in the bootlinux role. If you need to update a kernel configuration for whatever reason, please submit a patch for the bootlinux role upstream.

License

This work is licensed under the GPLv2, refer to the LICENSE file for details. Please stick to SPDX annotations for file license annotations. If a file has no SPDX annotation the GPLv2 applies. We keep SPDX annotations with permissive licenses to ensure upstream projects we embraced under permissive licenses can benefit from our changes to their respective files.