¿Cómo se prueba el núcleo de Linux?

¿Cómo prueban los desarrolladores del kernel de Linux su código localmente y después de que lo hayan comprometido? ¿Usan algún tipo de prueba unitaria, automatización de comstackción? planes de prueba?

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

Por lo general, cualquier desarrollador probará su propio código antes de enviarlo, y muy a menudo usarán una versión de desarrollo del kernel de Linus, o uno de los otros árboles de desarrollo / inestable para un proyecto relevante para su trabajo. Esto significa que a menudo están probando tanto sus cambios como los de otras personas.

No suele haber mucho en el camino de los planes de prueba formales, pero se pueden solicitar pruebas adicionales antes de que las características se fusionen en árboles ascendentes.

Como señaló Dean, también hay algunas pruebas automatizadas, el proyecto de prueba de Linux y el autotest del kernel ( buena visión general ).

Los desarrolladores a menudo también escribirán pruebas automatizadas para evaluar su cambio, pero no estoy seguro de que haya un mecanismo (a menudo utilizado) para recostackr de manera central estas pruebas adhoc.

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

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

El Linux Test Project (LTP) ofrece suites de prueba para la comunidad de código abierto que validan la confiabilidad y la estabilidad de Linux. El paquete de pruebas LTP contiene una colección de herramientas para probar el kernel de Linux y las funciones relacionadas. https://github.com/linux-test-project/ltp

Autotest : un marco para pruebas totalmente automáticas. Está diseñado principalmente para probar el kernel de Linux, aunque es útil para muchos otros propósitos, como la calificación de nuevo hardware, pruebas de virtualización y otras pruebas generales del progtwig de espacio del usuario bajo 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 existen sistemas de certificación desarrollados por algunas de las principales compañías distribuidoras 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 dynamic del kernel de Linux:

Kmemleak es un detector de fuga de memoria incluido en el kernel de Linux. Proporciona una forma de detectar posibles memory leaks del kernel de forma similar a un recolector de elementos no utilizados 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 asignada 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 kernel. También es una parte de Linux Kernel

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 que lo hayan comprometido?

¿Usan algún tipo de prueba unitaria, automatización de comstackción?

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

P.ej. Ingo Molnar está ejecutando la siguiente carga de trabajo: 1. comstackr un kernel nuevo con un conjunto aleatorio de opciones de configuración 2. reiniciar 3. ir a 1

Cada falla de comstackción, falla de arranque, ERROR o advertencia de tiempo de ejecución es tratada. 24/7. Multiplique por varios cuadros, y uno puede descubrir bastantes problemas.

planes de prueba?

No.

Puede haber malentendidos de que existe una instalación central de pruebas, no hay ninguna. Todos hacen lo que él quiere.

No es muy fácil automatizar las pruebas de kernel. La mayoría de los desarrolladores de Linux hacen las pruebas por su cuenta, al igual que adobriyan mencionado.

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 tener que volver al BIOS, y si falla, reiniciar de nuevo.
  • dmesg: Definitivamente el lugar para buscar información sobre lo que sucedió durante el arranque del kernel y si funciona / no funciona.
  • Kernel Instrumentation: 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 encender MUCHOS rastreadores que les permiten depurar qué está sucediendo.

Entonces, los desarrolladores generalmente hacen que otros revisen sus parches. Una vez que los parches se revisan localmente y se ha comprobado que no interfieren con ninguna otra cosa, y se prueba que los parches funcionan con el núcleo más reciente de Linus sin romper nada, los parches se empujan hacia arriba.

Editar: Aquí hay un bonito video que detalla el proceso por el que pasa un parche antes de que se integre en el kernel.

Herramientas en el árbol

Una buena forma de encontrar herramientas de prueba en el kernel es:

  • make help y lee todos los objectives
  • mira bajo herramientas / prueba

En v4.0, esto me lleva a:

Kernel CI

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

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

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

Linaro Lava

http://www.linaro.org/initiatives/lava/ se parece a un sistema de CI con enfoque en el tablero de desarrollo y el kernel de Linux.

ARM 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 vale la pena echarle un vistazo.

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

Depuradores de pasos

No es realmente una prueba unitaria, pero puede ayudar una vez que las pruebas comienzan a fallar:

Además de los puntos arriba / abajo, 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.

En realidad, pasan muchas pruebas, en realidad guiones, herramientas de análisis de códigos estáticos, revisiones de códigos, etc., que son muy eficientes en la detección de errores, que de otro modo 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 progtwig que hace coincidir y el motor de transformación que proporciona el lenguaje SmPL (Semantic Patch Language) para especificar coincidencias y transformaciones deseadas en el código C.

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

También hay:

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

https://github.com/gormanm/mmtests

Trinity que es un probador de fuzz de llamada del sistema Linux

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

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

Me imagino que utilizan 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 del kernel, así que imagino que también se usa.

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

LTP y Memtests generalmente son herramientas preferidas.

adobriyan mencionó el ciclo de Ingo de pruebas de comstackción de configuraciones aleatorias. Eso está prácticamente cubierto por el bot de prueba de 0 días (también conocido como bot de prueba de kbuild). Un buen artículo sobre la infraestructura se presenta aquí: 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 antes posible. (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 comstackción del kernel de Linux y realicé algunas modificaciones para Android (Marshmallow y Nougat) en las que utilizo la versión de Linux 3. Lo compilé en el sistema Linux, depuré los errores manualmente y luego ejecuté su archivo de imagen de arranque en Android y verifico si estaba yendo en un agujero de bucle o no. Si funciona perfecto, significa que está comstackdo perfectamente según los requisitos del sistema.
Para la comstackción del kernel de MotoG

NOTA: – Linux Kernel cambiará según los requisitos que dependen del hardware del sistema