¿Cómo se prueba el kernel de Linux?

¿Cómo prueban los desarrolladores del kernel de Linux su código localmente y después de haberlo confirmado? ¿Utilizan algún tipo de prueba unitaria, automatización de construcción? planes de prueba?

El kernel de Linux tiene un fuerte énfasis en las pruebas comunitarias.

Normalmente, cualquier desarrollador probará su propio código antes de enviarlo, y con bastante frecuencia utilizará una versión de desarrollo del núcleo de Linus, o uno de los otros árboles inestables / de desarrollo para un proyecto relevante para su trabajo. Esto significa que a menudo están probando tanto sus cambios como los cambios de otras personas.

Los planes de prueba formales tienden a no ser muchos, pero se pueden solicitar pruebas adicionales antes de fusionar las características en los árboles aguas arriba.

Como señaló Dean, también hay algunas pruebas automatizadas, el proyecto de prueba de Linux y la prueba automática del núcleo ( buena descripción general ).

Los desarrolladores a menudo también escriben pruebas automatizadas destinadas a probar su cambio, pero no estoy seguro de que haya un mecanismo (utilizado a menudo) para recopilar centralmente estas pruebas ad hoc.

Por supuesto, depende mucho de qué área del kernel se cambie: las pruebas que haría para un nuevo controlador de red son bastante diferentes de las pruebas que haría al reemplazar el algoritmo de programación central.

Naturalmente, el núcleo en sí y sus partes se prueban antes del lanzamiento, pero estas pruebas solo cubren la funcionalidad básica. Existen algunos sistemas de prueba que realizan pruebas de Kernel de Linux:

El Linux Test Project (LTP) entrega conjuntos de pruebas a la comunidad de código abierto que validan la confiabilidad y estabilidad de Linux. El conjunto de pruebas LTP contiene una colección de herramientas para probar el kernel de Linux y características relacionadas. https://github.com/linux-test-project/ltp

Auto prueba : un marco para pruebas totalmente automatizadas. Está diseñado principalmente para probar el kernel de Linux, aunque es útil para muchos otros propósitos, como la calificación de hardware nuevo, pruebas de virtualización y otras pruebas generales de programas de espacio de usuario en plataformas Linux. Es un proyecto de código abierto bajo la GPL y es utilizado y desarrollado por varias organizaciones, incluidas Google, IBM, Red Hat y muchas otras. http://autotest.github.io/

También hay sistemas de certificación desarrollados por algunas de las principales compañías de distribución de GNU / Linux. Estos sistemas generalmente verifican las distribuciones completas de GNU / Linux para la compatibilidad con el hardware. Existen sistemas de certificación desarrollados por Novell, Red Hat, Oracle, Canonical, Google .

También hay sistemas para el análisis dinámico del kernel de Linux:

Kmemleak es un detector de pérdida de memoria incluido en el kernel de Linux. Proporciona una forma de detectar posibles fugas de memoria del núcleo de una manera similar a un recolector de basura de rastreo con la diferencia de que los objetos huérfanos no se liberan sino que solo se informan a través de / sys / kernel / debug / kmemleak.

Kmemcheck atrapa cada lectura y escritura en la memoria que se asignó dinámicamente (es decir, con kmalloc ()). Si se lee una dirección de memoria que no se ha escrito previamente, se imprime un mensaje en el registro del núcleo. También es parte del kernel de Linux

El Marco de inyección de fallas (incluido en el kernel de Linux) permite infundir errores y excepciones en la lógica de una aplicación para lograr una mayor cobertura y tolerancia a fallas del sistema.

¿Cómo prueban los desarrolladores del kernel de Linux su código localmente y después de haberlo confirmado?

¿Utilizan algún tipo de prueba unitaria, automatización de construcción?

En el sentido clásico de las palabras, no.

P.ej. Ingo Molnar está ejecutando la siguiente carga de trabajo: 1. construir un nuevo núcleo con un conjunto aleatorio de opciones de configuración 2. iniciar en él 3. ir a 1

Se trata cada advertencia de falla de compilación, falla de arranque, ERROR o tiempo de ejecución. 24/7. Multiplique por varias cajas, y uno puede descubrir bastantes problemas.

planes de prueba?

No.

Puede haber malentendidos de que hay una instalación de prueba central, no hay ninguno. Todo el mundo hace lo que quiere.

Herramientas en el árbol

Una buena manera de encontrar herramientas de prueba en el núcleo es:

• make help y lee todos los objetivos
• mirar debajo de herramientas / pruebas

En v4.0, esto me lleva a:

• kselftest bajo herramientas / testing / selftests . Corre con make kselftest. Debe estar ejecutando el núcleo construido ya. Ver también: Documentation / kselftest.txt , https://kselftest.wiki.kernel.org/

• ktest bajo herramientas / testing / ktest . Ver también: http://elinux.org/Ktest , http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest

• Sección de analizadores estáticos de make help, que contiene objetivos como:

  • checkstack: Perl: ¿qué hace checkstack.pl en linux source?
  • coccicheck para Coccinelle (mencionado por askb )

Kernel CI

https://kernelci.org/ es un proyecto que tiene como objetivo hacer que las pruebas de kernel sean más automatizadas y visibles.

Parece que solo hace pruebas de compilación y arranque (TODO cómo probar automáticamente que el arranque funcionó La fuente debe estar en https://github.com/kernelci/ ).

Linaro parece ser el principal responsable del proyecto, con contribuciones de muchas grandes empresas: https://kernelci.org/sponsors/

Lava Linaro

http://www.linaro.org/initiatives/lava/ parece a un sistema de CI centrado en el desarrollo de la placa de desarrollo y el kernel de Linux.

BRAZO LISA

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

No estoy seguro de lo que hace en detalle, pero es por ARM y Apache con licencia, por lo que probablemente valga la pena echarle un vistazo.

Demostración: https://www.youtube.com/watch?v=yXZzzUEngiU

Depuradores de pasos

En realidad, no son pruebas unitarias, pero pueden ayudar una vez que sus pruebas comienzan a fallar:

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

Mi propia configuración QEMU + Buildroot + Python

También comencé una configuración centrada en la facilidad de desarrollo, pero también terminé agregando algunas capacidades de prueba simples: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508782827320209644dcbaf9a6b3141724#test-this -repo

No he analizado todas las otras configuraciones con gran detalle, y es probable que hagan mucho más que las mías, sin embargo, creo que mi configuración es muy fácil de comenzar rápidamente porque tiene mucha documentación y automatización.

No es muy fácil automatizar las pruebas de kernel. La mayoría de los desarrolladores de Linux hacen las pruebas por su cuenta, como mencionó adobriyan.

Sin embargo, hay algunas cosas que ayudan a depurar el kernel de Linux:

• kexec: una llamada al sistema que le permite poner otro kernel en la memoria y reiniciar sin volver al BIOS, y si falla, reinicie nuevamente.
• dmesg: Definitivamente el lugar donde buscar información sobre lo que sucedió durante el arranque del kernel y si funciona / no funciona.
• Instrumentación del kernel: además de printk's (y una opción llamada 'CONFIG_PRINTK_TIME' que le permite ver (con una precisión de microsegundos) cuando el kernel genera qué), la configuración del kernel le permite activar MUCHOS trazadores que les permiten depurar qué está sucediendo.

Luego, los desarrolladores suelen hacer que otros revisen sus parches. Una vez que los parches se revisan localmente y se ve que no interfieren con nada más, y los parches se prueban para que funcionen con el último núcleo de Linus sin romper nada, los parches se colocan en sentido ascendente.

Editar: Aquí hay un buen video que detalla el proceso que atraviesa un parche antes de integrarse en el núcleo.

Además de los puntos anteriores / inferiores, que hacen más hincapié en las pruebas de funcionalidad, las pruebas de certificación de hardware y las pruebas de rendimiento del kernel de Linux.

Realmente se realizan muchas pruebas, scripts, herramientas de análisis de código estático, revisiones de código, etc., que es muy eficiente para detectar errores, que de lo contrario romperían algo en la aplicación.

Sparse : una herramienta de código abierto diseñada para encontrar fallas en el kernel de Linux.

Coccinelle es otro programa que hace coincidir y transformar el motor que proporciona el lenguaje SmPL (Semantic Patch Language) para especificar las coincidencias y transformaciones deseadas en el código C.

checkpatch.pl y otros scripts : los problemas de estilo de codificación se pueden encontrar en el archivo Documentation / CodingStyle en el árbol de fuentes del núcleo. Lo importante para recordar al leerlo no es que este estilo sea de alguna manera mejor que cualquier otro estilo, solo que es consistente. esto ayuda a los desarrolladores a encontrar y corregir fácilmente los problemas de estilo de codificación, se ha desarrollado el script scripts / checkpatch.pl en el árbol de fuentes del núcleo. Este script puede señalar problemas fácilmente y siempre debe ser ejecutado por un desarrollador en sus cambios, en lugar de que un revisor pierda su tiempo señalando problemas más adelante.

Me imagino que usan la virtualización para hacer pruebas rápidas, algo así como QEMU, VirtualBox o Xen, y algunos scripts para realizar configuraciones y pruebas automatizadas.

Las pruebas automatizadas probablemente se realicen probando muchas configuraciones aleatorias o algunas específicas (si están trabajando con un problema específico). Linux tiene muchas herramientas de bajo nivel (como dmesg) para monitorear y registrar datos de depuración desde el kernel, así que imagino que también se usa.

También hay:

MMTests, que es una colección de puntos de referencia y scripts para analizar los resultados

https://github.com/gormanm/mmtests

Trinidad, que es el sistema de Linux llamada fuzz tester

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

Además, las páginas LTP en sourceforge están bastante desactualizadas y el proyecto se ha trasladado a GitHub https://github.com/linux-test-project/ltp

Hasta donde yo sé, hay una herramienta de verificación de regresión de rendimiento automática (llamada lkp / 0 días) ejecutada / financiada por Intel, probará cada parche válido enviado a la lista de correo y verificará los puntajes cambiados de diferentes microbenchmarks como hackbench , fio, unixbench, netperf, etc., una vez que haya una regresión / mejora del rendimiento, se enviará un informe correspondiente directamente al autor del parche y a los encargados de mantenimiento relacionados con Cc.

LTP y Memtests son generalmente herramientas preferidas.

adobriyan mencionó el ciclo de Ingo de pruebas de configuración aleatoria. Eso está prácticamente cubierto por el bot de prueba de 0 días (también conocido como bot de prueba kbuild). Aquí se presenta un buen artículo sobre la infraestructura: Kernel Build / boot testing

La idea detrás de esta configuración es notificar a los desarrolladores lo antes posible para que puedan rectificar los errores lo suficientemente pronto. (antes de que los parches lleguen al árbol de Linus en algunos casos ya que la infraestructura de kbuild también prueba contra los árboles del subsistema del mantenedor)

Hice la compilación del kernel de Linux y realicé algunas modificaciones para Android (Marshmallow y Nougat) en las que utilizo la versión 3. de Linux. iba en bucle o no. Si funciona perfecto, significa que se compila perfectamente según los requisitos del sistema.
Para la compilación del kernel de MotoG

NOTA: - El kernel de Linux cambiará de acuerdo con los requisitos que dependen del hardware del sistema

Una vez que los contribuyentes envían sus archivos de parche y después de realizar la solicitud de fusión, los controladores de acceso de Linux están verificando el parche integrándolo y revisándolo. Una vez que tenga éxito, fusionarán el parche en la rama correspondiente y lanzarán una nueva versión. Proyecto de prueba de Linux ( https://github.com/linux-test-project/ltp ) es la fuente principal que proporciona escenarios de prueba (Casos de prueba) para ejecutar contra el núcleo después de aplicar parches. Esto puede tomar alrededor de 2 ~ 4 horas y depende. Tenga en cuenta con respecto al sistema de archivos del kernel seleccionado que se va a probar. Ej: Ext4 genera resultados diferentes contra EXT3 y así sucesivamente.

Procedimiento de prueba de kernel.

1. Obtenga la última fuente de kernel del repositorio. ( Https://www.kernel.org/ o Github.com)
2. Aplicar archivo de parche (usando la herramienta Diff)
3. Construir nuevo kernel.
4. Prueba contra procedimientos de prueba en LTP ( https://github.com/linux-test-project/ltp )