versiones sistema que operativo informacion entre distribuciones diferencias caracteristicas linux linux-kernel

sistema - que es linux wikipedia



¿Cómo se prueba el kernel de Linux? (12)

¿Cómo hacen los desarrolladores del kernel de Linux para probar su código localmente y después de que se hayan comprometido? ¿Utilizan algún tipo de prueba unitaria, automatización de la construcción? planes de prueba?

¿Cómo hacen los desarrolladores del kernel de Linux para probar su código localmente y después de que se hayan comprometido?

¿Utilizan algún tipo de prueba unitaria, automatización de la 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 kernel con un conjunto aleatorio de opciones de configuración 2. arrancar en él 3. ir a 1

Cada falla de compilación, falla de arranque, BUG o advertencia de tiempo de ejecución es tratada. 24/7. Multiplica por varias cajas, y uno puede descubrir muchos problemas.

planes de prueba?

No.

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

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.

En realidad se realizan muchas pruebas, en realidad scripts, herramientas de análisis de código estático, revisiones de código, etc. que son muy eficientes para detectar 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 programa que hace el motor de coincidencia y 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 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 sea consistente. esto ayuda a los desarrolladores a encontrar y solucionar fácilmente problemas de estilo de codificación, se han desarrollado los scripts / checkpatch.pl en el árbol de fuentes del núcleo. Esta secuencia de comandos puede señalar problemas fácilmente, y siempre debe ser ejecutada por un desarrollador en sus cambios, en lugar de que un revisor pierda su tiempo al señalar los problemas más adelante.

El kernel de Linux tiene un gran énfasis en las pruebas de la comunidad.

Normalmente, cualquier desarrollador probará su propio código antes de enviarlo, y muy a menudo estará usando una versión de desarrollo del núcleo 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 cambios de otras personas.

No suele haber muchos planes formales de prueba, pero es posible que se soliciten pruebas adicionales antes de que las características se fusionen en los árboles río arriba.

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

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

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

Había hecho la compilación del kernel de Linux y algunas modificaciones para Android (Marshmallow y Nougat) en las que uso la versión 3. de Linux. Lo compilé en el sistema Linux, depuro los errores manualmente y luego ejecuto su archivo de imagen de arranque en Android y verifico si Estaba entrando en el agujero de bucle o no. Si funciona a la perfección, significa que se compila perfectamente de acuerdo con los requisitos del sistema.
Para la compilación del núcleo de MotoG

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

LTP y Memtests son herramientas generalmente preferidas.

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

La prueba automática se realiza probando varias 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.

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

El Proyecto de prueba de Linux (LTP) ofrece suites de prueba a la comunidad de código abierto que valida la confiabilidad y estabilidad de Linux. El conjunto 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 completamente automatizadas. Está diseñado principalmente para probar el kernel de Linux, aunque es útil para muchos otros propósitos, como calificar hardware nuevo, pruebas de virtualización y otras pruebas de programas de espacio de usuarios en general en plataformas Linux. Es un proyecto de código abierto bajo la GPL y es utilizado y desarrollado por varias organizaciones, entre ellas 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 usualmente verifican las distribuciones completas de GNU / Linux para verificar 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 fugas de memoria incluido en el kernel de Linux. Proporciona una forma de detectar posibles fugas de memoria del kernel de forma similar a un recolector de basura con la diferencia de que los objetos huérfanos no se liberan sino que solo se informan mediante / 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 anteriormente, 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.

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

Sin embargo, hay algunas cosas que ayudan con la depuración del Kernel de Linux:

  • kexec: una llamada del sistema que le permite poner otro kernel en la memoria y reiniciar sin volver a la BIOS y, si falla, reiniciar.
  • dmesg: Definitivamente, el lugar donde buscar información sobre lo que sucedió durante el arranque del kernel y si funciona o 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 la salida del kernel es lo que hace), la configuración del kernel le permite activar MUCHOS trazadores que les permiten depurar está sucediendo.

Luego, los desarrolladores suelen hacer que otros revisen sus parches. Una vez que los parches se revisan localmente y se observa que no interfieren con ninguna otra cosa, y los parches se prueban para que funcionen con el último kernel de Linus sin romper nada, los parches se empujan hacia arriba.

Edición: Aquí hay un buen video que detalla el proceso por el que pasa un parche antes de que se integre en el kernel.

Por lo que sé, hay una herramienta de comprobación de regresión de rendimiento automática (denominada lkp / 0 día) ejecutada / financiada por Intel, probará cada parche válido enviado a la lista de correo y verificará los puntajes cambiados desde 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 mantenedores relacionados con Cc.

adobriyan mencionó el ciclo de Ingo de pruebas de compilación de configuraciones aleatorias Eso está prácticamente cubierto por el bot de prueba de 0 días (también conocido como kbuild test bot). Un buen artículo sobre la infraestructura se presenta aquí: lwn.net/Articles/514278

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

Herramientas en el arbol

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

En v4.0, esto me lleva a:

Kernel CI

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

Parece que solo se realizan pruebas de compilación y arranque (TODO cómo probar automáticamente que la fuente de arranque funcionó 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/ parece un sistema de CI con enfoque 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 vale la pena echarle un vistazo.

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

Depuradores de pasos

Realmente no son pruebas unitarias, pero pueden ayudar una vez que tus pruebas comiencen a fallar:

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