Como o kernel do Linux é testado?

Como os desenvolvedores do kernel Linux testam seu código localmente e depois que eles são confirmados? Eles usam algum tipo de teste de unidade, constroem automação? planos de teste?

O kernel do linux tem uma forte ênfase nos testes da comunidade.

Normalmente, qualquer desenvolvedor testará seu próprio código antes de enviá-lo e, com frequência, estará usando uma versão de desenvolvimento do kernel da Linus, ou uma das outras árvores instáveis ​​/ de desenvolvimento para um projeto relevante ao seu trabalho. Isso significa que eles frequentemente estão testando suas alterações e as de outras pessoas.

Geralmente, os planos de teste formais não são muito complexos, mas testes extras podem ser solicitados antes que os recursos sejam mesclados nas árvores a montante.

Como Dean apontou, há também alguns testes automatizados, o projeto de teste do linux e o autoteste do kernel ( boa visão geral ).

Os desenvolvedores também costumam escrever testes automatizados direcionados para testar suas alterações, mas não tenho certeza de que exista um mecanismo (frequentemente usado) para coletar centralmente esses testes adhoc.

Depende muito de qual área do kernel está sendo alterada, é claro - o teste que você faria para um novo driver de rede é bem diferente do que você faria ao substituir o algoritmo de agendamento principal.

Naturalmente, o próprio kernel e suas partes são testados antes do lançamento, mas esses testes cobrem apenas a funcionalidade básica. Existem alguns sistemas de teste que realizam testes do Linux Kernel:

O Linux Test Project (LTP) fornece suítes de teste para a comunidade de código aberto que valida a confiabilidade e a estabilidade do Linux. O conjunto de testes LTP contém uma coleção de ferramentas para testar o kernel do Linux e recursos relacionados. https://github.com/linux-test-project/ltp

Autoteste - uma estrutura para testes totalmente automatizados. Ele foi projetado principalmente para testar o kernel do Linux, embora seja útil para muitos outros propósitos, como a qualificação de novo hardware, teste de virtualização e outros testes gerais do programa de espaço do usuário em plataformas Linux. É um projeto de código aberto sob a GPL e é usado e desenvolvido por várias organizações, incluindo Google, IBM, Red Hat e muitas outras. http://autotest.github.io/

Também existem sistemas de certificação desenvolvidos por algumas das principais empresas de distribuição GNU / Linux. Esses sistemas geralmente verificam distribuições completas do GNU / Linux quanto à compatibilidade com o hardware. Existem sistemas de certificação desenvolvidos pela Novell, Red Hat, Oracle, Canonical, Google .

Existem também sistemas para análise dinâmica do kernel do Linux:

O Kmemleak é um detector de vazamento de memória incluído no kernel do Linux. Ele fornece uma maneira de detectar possíveis vazamentos de memória do kernel de maneira semelhante a um coletor de lixo com a diferença de que os objetos órfãos não são liberados, mas apenas relatados via / sys / kernel / debug / kmemleak.

O Kmemcheck captura todas as leituras e gravações na memória que foram alocadas dinamicamente (ou seja, com kmalloc ()). Se for lido um endereço de memória que não tenha sido gravado anteriormente, uma mensagem será impressa no log do kernel. Também faz parte do Linux Kernel

A Estrutura de Injeção de Falhas (incluída no kernel do Linux) permite infundir erros e exceções na lógica de um aplicativo para obter uma cobertura e tolerância a falhas mais altas do sistema.

Como os desenvolvedores do kernel Linux testam seu código localmente e depois que eles são confirmados?

Eles usam algum tipo de teste de unidade, constroem automação?

No sentido clássico das palavras, não.

Por exemplo. O Ingo Molnar está executando a seguinte carga de trabalho: 1. construa um novo kernel com um conjunto aleatório de opções de configuração 2. inicialize nele 3. vá para 1

Cada falha de compilação, falha de inicialização, erro ou aviso de tempo de execução é tratado. 24/7. Multiplique por várias caixas, e pode-se descobrir muitos problemas.

planos de teste?

Não.

Pode haver um mal-entendido de que exista instalação central de testes, não existe. Todo mundo faz o que ele quer.

Ferramentas na árvore

Uma boa maneira de encontrar ferramentas de teste no kernel é:

• make help e leia todos os alvos
• procure em ferramentas / testes

Na v4.0, isso me leva a:

• kselftest em ferramentas / testes / autotestes . Corra com make kselftest. Já deve estar executando o kernel construído. Veja também: Documentation / kselftest.txt , https://kselftest.wiki.kernel.org/

• ktest em tools / testing / ktest . Veja também: http://elinux.org/Ktest , http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest

• Analisadores estáticos de make help, que contém alvos como:

  • checkstack: Perl: o que o checkstack.pl na fonte linux faz?
  • coccicheckpara Coccinelle (mencionado por askb )

IC do kernel

https://kernelci.org/ é um projeto que visa tornar o teste do kernel mais automatizado e visível.

Parece fazer apenas testes de compilação e inicialização (o TODO, como testar automaticamente se a Origem funcionou na inicialização, deve estar em https://github.com/kernelci/ ).

Linaro parece ser o principal mantenedor do projeto, com contribuições de muitas grandes empresas: https://kernelci.org/sponsors/

Linaro Lava

http://www.linaro.org/initiatives/lava/ parece um sistema de IC com foco na criação de placas de desenvolvimento e no kernel do Linux.

ARM LISA

https://github.com/ARM-software/lisa

Não tenho certeza do que faz em detalhes, mas é licenciado pela ARM e Apache, provavelmente vale uma olhada.

Demonstração: https://www.youtube.com/watch?v=yXZzzUEngiU

Depuradores de etapas

Não é realmente um teste de unidade, mas pode ajudar quando seus testes começarem a falhar:

• QEMU + GDB: https://stackoverflow.com/a/42316607/895245
• KGDB: https://stackoverflow.com/a/44226360/895245

Minha própria configuração QEMU + Buildroot + Python

Também iniciei uma instalação focada na facilidade de desenvolvimento, mas acabei adicionando alguns recursos simples de teste: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508782827320209644dcbaf9a6b3141724#test-this -repo

Não analisei todas as outras configurações detalhadamente e elas provavelmente fazem muito mais do que as minhas, no entanto, acredito que minha configuração é muito fácil de ser iniciada rapidamente, pois possui muita documentação e automação.

Não é muito fácil automatizar os testes do kernel. A maioria dos desenvolvedores de Linux faz o teste por conta própria, assim como o adobriyan mencionado.

No entanto, existem algumas coisas que ajudam na depuração do kernel do Linux:

• kexec: uma chamada do sistema que permite colocar outro kernel na memória e reiniciar sem voltar ao BIOS e, se falhar, reinicie novamente.
• dmesg: Definitivamente, o lugar para procurar informações sobre o que aconteceu durante a inicialização do kernel e se funciona / não funciona.
• Instrumentação do kernel: além dos printk (e uma opção chamada 'CONFIG_PRINTK_TIME' que permite ver (com precisão de microssegundos) quando o kernel produz o que), a configuração do kernel permite ativar MUITOS rastreadores que permitem depurar o que está acontecendo.

Em seguida, os desenvolvedores geralmente solicitam que outros revisem seus patches. Depois que os patches são revisados ​​localmente e vistos como não interferindo em mais nada, e os patches são testados para trabalhar com o kernel mais recente da Linus sem quebrar nada, os patches são enviados a montante.

Edit: Aqui está um bom vídeo detalhando o processo pelo qual um patch passa antes de ser integrado ao kernel.

Além dos pontos acima / abaixo, que enfatizam mais os testes de funcionalidade, teste de certificação de hardware e teste de desempenho do kernel Linux.

Na verdade, muitos testes acontecem, na verdade scripts, ferramentas estáticas de análise de código, revisões de código etc., que são muito eficientes na detecção de bugs, o que de outra forma quebraria algo no aplicativo.

Esparso - Uma ferramenta de código aberto projetada para encontrar falhas no kernel do Linux.

Coccinelle é outro programa que faz o mecanismo de correspondência e transformação que fornece a linguagem SmPL (Semantic Patch Language) para especificar correspondências e transformações desejadas no código C.

checkpatch.pl e outros scripts - problemas de estilo de codificação podem ser encontrados no arquivo Documentation / CodingStyle na árvore de fontes do kernel. O importante a lembrar ao ler não é que esse estilo seja de alguma forma melhor do que qualquer outro estilo, apenas que seja consistente. isso ajuda os desenvolvedores a encontrar e corrigir problemas de estilo de codificação com facilidade, o script scripts / checkpatch.pl na árvore de fontes do kernel foi desenvolvido. Esse script pode apontar problemas facilmente e deve sempre ser executado por um desenvolvedor em suas alterações, em vez de fazer com que um revisor perca seu tempo apontando problemas mais tarde.

Eu imagino que eles usam a virtualização para fazer testes rápidos, algo como QEMU, VirtualBox ou Xen, e alguns scripts para executar configurações e testes automatizados.

Provavelmente, o teste automatizado é feito com várias configurações aleatórias ou algumas específicas (se elas estiverem funcionando com um problema específico). O Linux tem muitas ferramentas de baixo nível (como dmesg) para monitorar e registrar dados de depuração do kernel, então eu imagino que seja usado também.

Existem também:

MMTests, que é uma coleção de referências e scripts para analisar os resultados

https://github.com/gormanm/mmtests

Trinity, que é o testador de chamadas de sistema do Linux

http://codemonkey.org.uk/projects/trinity/

As páginas LTP na sourceforge também estão desatualizadas e o projeto foi transferido para o GitHub https://github.com/linux-test-project/ltp

Até onde eu sei, existe uma ferramenta de verificação de regressão de desempenho automaticamente (denominada lkp / 0 dia) em execução / financiamento pela Intel, ela testará cada patch válido enviado à lista de discussão e verificará as pontuações alteradas de diferentes marcas de microbiologia, como hackbench , fio, unixbench, netperf, etc., quando houver uma regressão / melhoria no desempenho, um relatório correspondente será enviado diretamente ao autor do patch e aos mantenedores relacionados ao Cc.

LTP e Memtests são geralmente ferramentas preferidas.

adobriyan mencionou o loop de teste de configuração aleatória da configuração do Ingo. Agora isso está praticamente coberto pelo bot de teste de 0 dias (também conhecido como bot de teste do kbuild). Um bom artigo sobre a infraestrutura é apresentado aqui: Kernel Build / boot testing

A idéia por trás dessa configuração é notificar os desenvolvedores o mais rápido possível, para que possam corrigir os erros em breve. (antes dos patches entrarem na árvore de Linus em alguns casos, pois a infraestrutura kbuild também testa contra as árvores do subsistema do mantenedor)

Eu fiz a compilação do kernel do linux e fiz algumas modificações para o Android (Marshmallow e Nougat) nas quais uso a versão 3. do Linux. Compilei-o no sistema Linux, depurei os erros manualmente e executei o arquivo de imagem de inicialização no Android e verifique se estava entrando ou não. Se funcionar perfeitamente, significa que é compilado perfeitamente de acordo com os requisitos do sistema.
Para a compilação do kernel do MotoG

NOTA: - O kernel do Linux será alterado de acordo com os requisitos que dependem do hardware do sistema

Uma vez depois que os contribuidores enviam seus arquivos de patch e depois de fazer a solicitação de mesclagem, os gatekeepers do linux estão verificando o patch, integrando e revisando-o. O Projeto de Teste do Linux ( https://github.com/linux-test-project/ltp ) é a principal fonte que fornece cenários de teste (casos de teste) para execução no kernel após a aplicação de patches. Isso pode levar cerca de 2 a 4 horas e depende. Observe que o sistema de arquivos do kernel selecionado será testado. Ex: Ext4 gera resultados diferentes em relação ao EXT3 e assim por diante.

Procedimento de teste do kernel.

1. Obtenha a fonte mais recente do kernel no repositório ( https://www.kernel.org/ ou Github.com)
2. Aplicar arquivo de correção (usando a ferramenta Diff)
3. Crie um novo kernel.
4. Teste contra procedimentos de teste no LTP ( https://github.com/linux-test-project/ltp )