Automação de testes para drivers out-of-tree do kernel Linux

Abstract

O uso de testes automatizados de software já é o padrão da indústria de software de uma forma geral. O teste de software embarcado possui especificidades, principalmente na ca mada que é altamente dependente do hardware. A maioria dos frameworks de teste open source mais usados não se adequam a este contexto, principalmente no caso de drivers out-of-tree do kernel Linux. Um driver é chamado de out-of-tree quando é mantido em repositório de código-fonte separado da árvore (repositório) do kernel. Algumas restri ções se aplicam a esse tipo de driver: é comum ele precisar suportar várias versões de kernel, geralmente recorrendo a código que é condicionalmente compilado ou não, de pendendo de contra qual versão de kernel o driver está sendo compilado; no sistema em que o driver é executado, ele fica guardado em um arquivo binário separado do kernel, e é carregado sob demanda; o driver acaba não podendo ser testado com a maioria das ferramentas que são distribuídas com o kernel, pois estas foram criadas apenas para testar código que já está integrado no repositório do kernel. Este trabalho propõe o uso de uma combinação de ferramentas open source para gerar um ambiente próximo ao cenário real, o hardware final ou target, para então executar testes de unidade em drivers out-of-tree. Os requisitos da automação de teste e das ferramentas dessa automação são listados e a adequação das ferramentas é analisada. Uma pequena infraestrutura é implementada, usando o framework de teste embutido no Buildroot, que por sua vez usa qemu para si mular o target com um kernel vivo, e o framework KUnit, recentemente integrado no kernel, para realizar testes de unidade. Alguns casos de teste são criados para o estudo de caso, um driver open source, e um exemplo de ambiente de integração contínua é criado usando serviços online gratuitos para ilustrar a solução proposta. Todos os arquivos ne cessários para reproduzir os resultados desse trabalho são publicados como open source. A combinação de ferramentas open source selecionada é comparada com os requisitos previamente levantados e ela atende à necessidade de observabilidade e controlabilidade, enquanto executa testes de unidade em um ambiente o mais próximo possível do cenário real.

Automated software testing is the de facto standard in the software industry. Testing embedded software brings some specific challenges, specially for the software part highly coupled to the hardware. Most of the usual open-source test frameworks are not suitable to this context, specially when speaking about out-of-tree device drivers for the Linux kernel. A driver is called out-of-tree when it is maintained in a source-code repository separate from the kernel tree (repository). This kind of driver has some restrictions: it often needs to support multiple kernel versions, usually resorting to some code being conditionally compiled or not, depending on the kernel version the driver is compiled against; in the system in which the driver runs, it lives in a binary file separate from the kernel itself, and it is loaded on demand; it can’t be tested using most of tools distributed together to the kernel since these tools usually only support code already integrated to the kernel repository. This document proposes to use a composite of open-source tools to provide an environment close to the real scenario, the target hardware, to execute unit tests for out-of-tree drivers. The requirements for both the automated test and its tools are listed and the tools suitability is analyzed. A small infrastructure is developed, using both the test framework embedded in Buildroot, which in its turn uses qemu to simulate the target with a live kernel, and the recent KUnit framework from the kernel itself to run units tests. Some test cases are created for the case study, an open-source driver, and an example of a continuous integration pipeline is created using free online services in order to illustrate the proposed solution. All the files needed to reproduce the results from this document are released as open source. The composite of open-source tools is compared to previously listed requirements and it does accomplish the required observability and controllability, while running unit tests in an environment as close as possible to the real scenario.