En Pruebas de integración continua para el kernel de Linux , escribí sobre el proyecto Continuous Kernel Integration (CKI) y su misión de cambiar la forma en que trabajan los desarrolladores y mantenedores del kernel. Este artículo es una inmersión profunda en algunos de los aspectos más técnicos del proyecto y cómo encajan todas las piezas.
Todo comienza con un cambio
Cada característica interesante, mejora y error en el kernel comienza con un cambio propuesto por un desarrollador. Estos cambios aparecen en innumerables listas de correo para diferentes repositorios del kernel. Algunos repositorios se enfocan en ciertos subsistemas del núcleo, como almacenamiento o redes, mientras que otros se enfocan en aspectos generales del núcleo. El proyecto CKI entra en acción cuando los desarrolladores proponen un cambio, o conjunto de parches, en el kernel o cuando un mantenedor realiza cambios en el propio repositorio.
El proyecto CKI mantiene disparadores que monitorean estos conjuntos de parches y toman medidas. Los proyectos de software como Patchwork facilitan mucho este proceso al recopilar las contribuciones de múltiples parches en una sola serie de parches. Esta serie viaja como una unidad a través del sistema CKI y permite publicar un informe único sobre la serie.
Otros activadores observan el repositorio en busca de cambios. Esto ocurre cuando los mantenedores del kernel fusionan conjuntos de parches, revierten parches o crean nuevas etiquetas. Probar estos cambios críticos garantiza que los desarrolladores siempre tengan una base sólida para usar como base para escribir nuevos parches.
Todos estos cambios llegan a una canalización de GitLab y pasan por múltiples etapas y múltiples sistemas.
Preparar la compilación
Todo comienza con preparar el código fuente para el tiempo de compilación. Esto requiere clonar el repositorio, aplicar el conjunto de parches propuesto por el desarrollador y generar un archivo de configuración del kernel. Estos archivos de configuración tienen miles de opciones que activan o desactivan funciones, y los archivos de configuración difieren increíblemente entre las diferentes arquitecturas del sistema. Por ejemplo, un sistema x86_64 bastante estándar puede tener un montón de opciones disponibles en su archivo de configuración, pero un sistema s390x (computadoras centrales IBM zSeries) probablemente tenga muchas menos opciones. Algunas opciones pueden tener sentido en ese mainframe, pero no tienen ningún propósito en una computadora portátil de consumo.
El kernel avanza y se transforma en un artefacto fuente. El artefacto contiene el repositorio completo, con los parches aplicados y todos los archivos de configuración del núcleo necesarios para la compilación. Los núcleos ascendentes se mueven como tarball, mientras que los núcleos de Red Hat se convierten en un RPM de origen para el siguiente paso.
Montones de compilaciones
La compilación del kernel convierte el código fuente en algo que una computadora puede iniciar y usar. El archivo de configuración describe qué construir, los scripts en el núcleo describen cómo construirlo y las herramientas en el sistema (como GCC y glibc) hacen la construcción. Este proceso tarda un tiempo en completarse, pero el proyecto CKI necesita hacerlo rápidamente para cuatro arquitecturas:aarch64 (ARM de 64 bits), ppc64le (POWER), s390x (IBM zSeries) y x86_64. Es importante que compilemos los núcleos rápidamente para que podamos mantener manejable nuestra acumulación y los desarrolladores reciban comentarios rápidos.
Agregar más CPU proporciona muchas mejoras de velocidad, pero cada sistema tiene sus límites. El proyecto CKI compila núcleos dentro de contenedores en una implementación de OpenShift; aunque OpenShift permite toneladas de escalabilidad, la implementación todavía tiene una cantidad finita de CPU disponibles. El equipo de CKI asigna 20 CPU virtuales para compilar cada kernel. ¡Con cuatro arquitecturas involucradas, esto aumenta a 80 CPU!
Otro aumento de velocidad proviene de una herramienta llamada ccache. El desarrollo del kernel se mueve rápidamente, pero una gran parte del kernel permanece sin cambios incluso entre múltiples versiones. La herramienta ccache almacena en caché los objetos construidos (pequeñas piezas del núcleo general) durante la compilación en un disco. Cuando aparece otra compilación del kernel más tarde, ccache busca partes del kernel que no hayan cambiado y que vio antes. Ccache extrae el objeto almacenado en caché del disco y lo reutiliza. Esto permite compilaciones más rápidas y un menor uso general de la CPU. Los núcleos que tardaron 20 minutos en compilarse ahora corren hacia la meta en menos de unos minutos.
Tiempo de prueba
Más recursos de Linux
- Hoja de trucos de los comandos de Linux
- Hoja de trucos de comandos avanzados de Linux
- Curso en línea gratuito:Descripción general técnica de RHEL
- Hoja de trucos de red de Linux
- Hoja de trucos de SELinux
- Hoja de trucos de los comandos comunes de Linux
- ¿Qué son los contenedores de Linux?
- Nuestros últimos artículos sobre Linux
El núcleo pasa a su último paso:probar en hardware real. Cada núcleo arranca en su arquitectura nativa usando Beaker, y una miríada de pruebas comienzan a hurgar en él para encontrar problemas. Algunas pruebas buscan problemas simples, como problemas con contenedores o mensajes de error en el arranque. Otras pruebas profundizan en varios subsistemas del kernel para encontrar regresiones en llamadas al sistema, asignación de memoria y subprocesos.
Los grandes marcos de prueba, como Linux Test Project (LTP), contienen toneladas de pruebas que buscan regresiones problemáticas en el kernel. Algunas de estas regresiones podrían revertir las correcciones de seguridad críticas, y hay pruebas para garantizar que esas mejoras permanezcan en el kernel.
Queda un paso crítico cuando finalizan las pruebas:la elaboración de informes. Los desarrolladores y mantenedores del kernel necesitan un informe conciso que les diga exactamente qué funcionó, qué no funcionó y cómo obtener más información. Cada informe de CKI contiene detalles sobre el código fuente utilizado, los parámetros de compilación y el resultado de la prueba. Esa información ayuda a los desarrolladores a saber dónde comenzar a buscar para solucionar un problema. Además, ayuda a los mantenedores a saber cuándo es necesario retener un conjunto de parches para volver a examinarlo antes de que un error llegue a su repositorio de kernel.
Resumen
El equipo del proyecto CKI se esfuerza por evitar que los errores ingresen al kernel de Linux al proporcionar comentarios automatizados y oportunos a los desarrolladores y mantenedores del kernel. Este trabajo facilita su trabajo al encontrar la fruta madura que conduce a errores del kernel, problemas de seguridad y problemas de rendimiento.
Para obtener más información, puede asistir al CKI Hackfest del 12 al 13 de septiembre después de la Linux Plumbers Conference del 9 al 11 de septiembre en Lisboa, Portugal.