Жизненный цикл тестирования ядра Linux

Сейчас мы вникнем в технические аспекты тестирования ядра Linux проектом CKI (непрерывной интеграции ядра) от Red Hat.

Все начинается с изменений

Каждая интересная функция, улучшение и ошибка в ядре начинается с предложенного разработчиком изменения. Эти изменения появляются в списках рассылки для разных репозиториев ядра. Некоторые репозитории сосредоточены на определенных подсистемах ядра, таких как хранилище или сеть, а другие —  на более широких аспектах. Проект CKI начинает работу, когда разработчики предлагают изменения или исправления для ядра или когда сопровождающий вносит изменения в сам репозиторий. 

Проект CKI поддерживает триггеры, которые отслеживают эти наборы исправлений и принимают меры. Программные проекты, такие как Patchwork, значительно упрощают этот процесс: они объединяют несколько патчей в одну серию. Уже она проходит как единое целое через систему CKI и позволяет публиковать единственній отчет о серии. 

Другие триггеры следят за изменениями в репозитории. Это происходит, когда сопровождающие ядра объединяют наборы исправлений, отменяют исправления или создают новые теги. Тестирование этих критических изменений гарантирует, что разработчики всегда будут иметь базис для написания новых исправлений. 

Все эти изменения попадают в конвейер GitLab и проходят через несколько этапов и систем. 

Подготовка сборки

Все начинается с подготовки исходного кода к среде компиляции. Для этого необходимо копировать репозиторий, применить набор исправлений, предложенный разработчиком, и создать файл конфигурации ядра. Эти файлы имеют тысячи вариаций, которые включают или выключают функции, а файлы конфигурации сильно  различаются для разных архитектурных систем. 

Например, довольно стандартная система x86_64 в файле конфигурации может иметь множество параметров, но в системе s390x их гораздо меньше. Некоторые настройки  имеют смысл на мэйнфрейме, но не имеют смысла для потребительского ноутбука. 

Ядро продвигается вперед и превращается в исходный артефакт. Артефакт содержит весь репозиторий с примененными исправлениями и все файлы конфигурации ядра, необходимые для компиляции.

Компиляции

Компиляция ядра превращает исходный код в то, что компьютер может загружать и использовать. Конфигурационный файл описывает, что нужно собрать. Сценарии в ядре описывают, как это построить, а инструменты в системе (такие, как GCC и glibc) делают сборку. 

Этот процесс занимает некоторое время, но проекту CKI необходимо, чтобы он был выполнен быстро для четырех архитектур: aarch64 (64-разрядная ARM), ppc64le (POWER), s390x (IBM zSeries) и x86_64. Важно, чтобы ядра компилировались быстро, чтобы мы могли управлять нашим невыполненным журналом работы, а разработчики получали быструю обратную связь. 

Добавление дополнительных процессоров обеспечивает улучшение скорости, но у каждой системы есть свои ограничения. Проект CKI компилирует ядра в контейнерах в развертывании OpenShift; хотя OpenShift обеспечивает хорошую масштабируемость, развертывание все еще имеет ограниченное количество доступных процессоров. Команда CKI выделяет 20 виртуальных процессоров для компиляции каждого ядра. С четырьмя задействованными архитектурами это увеличивает до 80 процессоров! 

Еще одно увеличение скорости связано с инструментом ccache. Разработка ядра идет быстро, но большая часть ядра остается неизменной даже между несколькими выпусками. Инструмент ccache кэширует построенные объекты (небольшие части общего ядра) во время компиляции на диске. 

Когда позже происходит компиляция другого ядра, ccache ищет неизмененные части ядра, которые он видел раньше. Ccache извлекает кешированный объект с диска и повторно использует его. Это позволяет ускорить компиляцию и снизить общую загрузку ЦП. Ядра, для компиляции которых потребовалось 20 минут, теперь добираются до финиша менее чем за несколько минут. 

Время тестирования 

Ядро переходит к своему последнему этапу: тестированию на реальном оборудовании. Каждое ядро загружается на своей собственной архитектуре с использованием Beaker, и множество тестов начинают пытаться найти проблемы.

Некоторые тесты ищут простые проблемы: с контейнерами или сообщения об ошибках при загрузке. Другие тесты углубляются в различные подсистемы ядра, чтобы найти регрессии в системных вызовах, распределении памяти и потоках. 

Крупные среды тестирования, такие как Linux Test Project (LTP), содержат множество тестов, которые ищут проблемные регрессии в ядре. Некоторые из этих регрессов могут привести к откату критических исправлений безопасности, и существуют тесты, чтобы убедиться, что эти улучшения остались в ядре. 

После завершения тестов остается один важный шаг: создание отчетов. Разработчики ядра и сопровождающие нуждаются в кратком отчете, в котором им точно рассказывается, что сработало, что не сработало и как получить дополнительную информацию. 

Каждый отчет CKI содержит подробную информацию об используемом исходном коде, параметрах компиляции и результатах тестирования. Эта информация помогает разработчикам понять, с чего начать поиск решения проблемы. Кроме того, это помогает разработчикам узнать, когда нужно сохранить набор исправлений для еще одного просмотра, прежде чем ошибка попадет в их репозиторий ядра. 

Итог

Команда проекта CKI стремится предотвратить попадание ошибок в ядро Linux, обеспечивая своевременную автоматическую обратную связь с разработчиками ядра и сопровождающими. Эта работа упрощает их работу, так как они находят малоизвестные плоды, которые приводят к ошибкам ядра, проблемам безопасности и проблемам с производительностью. 

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *