¿Cómo se prueba el kernel de Linux?


258

¿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?


16
youtube.com/watch?v=L2SED6sewRw , en algún lugar, no puedo recordar exactamente, pero creo que en la sección de control de calidad se está hablando de esto.
Anders

66
El enlace de Anders es excelente: un Google Tech Talk de uno de los principales desarrolladores de kernel, Greg Kroah Hartman. Valida la respuesta dada a continuación por el desarrollador de kernel @adobriyan. Greg observa lo divertido del núcleo: no hay una buena forma de probar sin ejecutarlo, es difícil hacer pruebas unitarias, etc., muchas permutaciones. "Confiamos en la comunidad de desarrollo para realizar pruebas. Queremos tantas pruebas funcionales como podamos, y también pruebas de rendimiento". Un enlace directo a la discusión de prueba es youtube.com/…
nealmcb

Con la popularidad de las máquinas virtuales, ¿no sería posible automatizar esto construyendo el núcleo con un montón de permutaciones de configuración e intentando arrancarlas? No sería una prueba de "unidad" de ninguna manera, pero podría atrapar errores.
Daniel Kaplan

@DanielKaplan: si supone que hay aproximadamente 1000 placas base que tienen una de 10 CPU, más 3 de 1000 dispositivos PCI, más 3 de 1000 dispositivos USB; y que el núcleo tiene 1000 opciones diferentes de tiempo de compilación posiblemente; entonces estás viendo alrededor de 1000 * 10 * 1000 * 999 * 9981000 * 999 * 998 * 1000 permutaciones posibles para probar. Si realiza una buena prueba de grabación de 8 horas para cada permutación y tiene un grupo de 100 servidores para ejecutar 400 máquinas virtuales en paralelo al mismo tiempo; luego, para cuando haya probado una millonésima parte de los resultados, todos serán obsoletos porque alguien cambió el código y usted debe comenzar de nuevo.
Brendan

Hay una pequeña discusión sobre las pruebas unitarias en ycombinator.
joeytwiddle

Respuestas:


76

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.


8
+1, la mitad de la batalla simplemente no está rompiendo algo de lo que los conductores dependen, de ahí la persistencia del BKL a lo largo de los años. La otra cosa a considerar es probar muchos subsistemas en muchas arquitecturas diferentes, lo que solo es prácticamente factible con el tipo de abuso de la comunidad, err testing, que recibe Linux.
Tim Post

66

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.


62

¿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.


66
Dada la existencia de sitios como este y este , también cuestionaría la validez de esta respuesta.
Dean Harding

3
Creo que el núcleo de la respuesta de adobriyan "hay un centro de pruebas central, no hay ninguno". es correcto Sin embargo, diferentes grupos realizan diferentes niveles de prueba, no es como si el núcleo no estuviera completamente probado.
stsquad el

2
Creo que tanto SUSE como RedHat además de probar sus propios núcleos, prueban la vainilla con frecuencia. No hay pruebas centrales per se, pero hay una prueba en marcha, sin embargo, por los principales usuarios de Linux. De lo contrario, el comentario se mantiene. Si se escribiera con menos sarcasmo, incluso lo habría modificado.
Dummy00001

55
Errr, ¿se dan cuenta de que Alexey Dobriyan es un desarrollador de kernel de Linux?
ninjalj

9
Como otro desarrollador de kernel, debo decir que esta es la respuesta más honesta a la pregunta: el kernel NO se prueba en el sentido clásico, simplemente porque es imposible. Hay más combinaciones de configuración y hardware que el tiempo disponible del desarrollador para probar. Muy pocas personas tienen las habilidades necesarias para probar ciertos dispositivos y, en algunos casos, muy pocas personas poseen ciertos dispositivos.
Ezequiel García

19

Herramientas en el árbol

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

En v4.0, esto me lleva a:

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:

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.


13

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.


6

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.


3

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.


Definitivamente tienes razón. Cuando hice el desarrollo de mi módulo de kernel, dependí en gran medida de VirtualBox + KGDB para que LINE-BY-LINE rastreara la ejecución del kernel. Sí, gdb para ver que todo el núcleo se ejecuta línea por línea es realmente genial. Lo mismo con Valerie Aurora, famosa desarrolladora de kernel, por ejemplo: youtube.com/watch?v=Tach2CheAc8 . Dentro del video puedes ver cómo usa la virtualización UserModeLinux para recorrer el núcleo.
Peter Teoh el


1

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.



0

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)


0

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


0

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 )
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.