Как тестируется ядро ​​Linux?

Как разработчики ядра Linux тестируют свой код локально и после того, как они его зафиксировали? Они используют какое-то модульное тестирование, автоматизацию сборки? планы испытаний?

Ядро linux уделяет большое внимание тестированию сообщества.

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

Как правило, формальных планов тестирования не так много, но может потребоваться дополнительное тестирование, прежде чем функции будут объединены в деревья верхнего уровня.

Как отметил Дин, есть также несколько автоматических тестов, проект тестирования linux и автотест ядра ( хороший обзор ).

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

Конечно, многое зависит от того, какая область ядра изменяется - тестирование, которое вы проводите для нового сетевого драйвера, совершенно отличается от тестирования, которое вы проводите при замене алгоритма планирования ядра.

Естественно, само ядро ​​и его части тестируются перед выпуском, но эти тесты охватывают только основные функциональные возможности. Существует несколько систем тестирования, которые выполняют тестирование ядра Linux:

Linux Test Project (LTP) предоставляет тестовые наборы сообществу разработчиков с открытым исходным кодом, которые проверяют надежность и стабильность Linux. Набор тестов LTP содержит набор инструментов для тестирования ядра Linux и связанных с ним функций. https://github.com/linux-test-project/ltp

Автотест - это фреймворк для полностью автоматизированного тестирования. Он предназначен в первую очередь для тестирования ядра Linux, хотя он полезен для многих других целей, таких как квалификация нового оборудования, тестирование виртуализации и другое общее тестирование программ пользовательского пространства на платформах Linux. Это проект с открытым исходным кодом под лицензией GPL, который используется и разрабатывается рядом организаций, в том числе Google, IBM, Red Hat и многими другими. http://autotest.github.io/

Также существуют системы сертификации, разработанные некоторыми крупными дистрибьюторскими компаниями GNU / Linux. Эти системы обычно проверяют полные дистрибутивы GNU / Linux на совместимость с оборудованием. Существуют системы сертификации, разработанные Novell, Red Hat, Oracle, Canonical, Google .

Существуют также системы для динамического анализа ядра Linux:

Kmemleak - это детектор утечки памяти, включенный в ядро ​​Linux. Он предоставляет способ обнаружения возможных утечек памяти ядра способом, подобным трассирующему сборщику мусора, с той разницей, что потерянные объекты не освобождаются, а сообщаются только через / sys / kernel / debug / kmemleak.

Kmemcheck каждое чтение и запись в память, которая была выделена динамически (то есть с помощью kmalloc ()). Если читается адрес памяти, который ранее не был записан, в журнал ядра выводится сообщение. Также входит в состав ядра Linux

Fault Injection Framework (входит в состав ядра Linux) позволяет включать ошибки и исключения в логику приложения для достижения более высокого охвата и отказоустойчивости системы.

Как разработчики ядра Linux тестируют свой код локально и после того, как они его зафиксировали?

Они используют какое-то модульное тестирование, автоматизацию сборки?

В классическом смысле слова нет.

Например Ingo Molnar выполняет следующую рабочую нагрузку: 1. собрать новое ядро ​​со случайным набором параметров конфигурации 2. загрузиться в него 3. перейти к 1

Каждый сбой сборки, сбой загрузки, ошибка или предупреждение во время выполнения обрабатываются. 24/7. Умножьте на несколько полей, и вы сможете обнаружить довольно много проблем.

планы испытаний?

Нет.

Там может быть недоразумение, что есть центральный испытательный центр, его нет. Каждый делает то, что хочет.

Внутренние инструменты

Хороший способ найти инструменты тестирования в ядре:

• make help и прочитайте все цели
• смотреть под инструменты / тестирование

В версии 4.0 это приводит меня к:

• kselftest под инструменты / тестирование / самотестирование . Беги с make kselftest. Должно быть уже запущено встроенное ядро. Смотрите также: Документация / kselftest.txt , https://kselftest.wiki.kernel.org/

• ktest под инструменты / тестирование / ktest . Смотрите также: http://elinux.org/Ktest , http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest

• Раздел статических анализаторовmake help , который содержит цели, такие как:

  • checkstack: Perl: что делает checkstack.pl в linux source?
  • coccicheckдля Coccinelle (упомянутый askb )

Ядро CI

https://kernelci.org/ - это проект, цель которого сделать тестирование ядра более автоматизированным и наглядным.

Похоже, что он выполняет только тесты сборки и загрузки (чтобы узнать, как автоматически проверить, что загрузка работала, источник должен быть на https://github.com/kernelci/ ).

Похоже, что Линаро является основным спонсором проекта с участием многих крупных компаний: https://kernelci.org/sponsors/

Линаро Лава

http://www.linaro.org/initiatives/lava/ выглядит как система CI с акцентом на сборку доски разработки и ядра Linux.

АРМ ЛИЗА

https://github.com/ARM-software/lisa

Не уверен, что он делает в деталях, но это ARM и Apache Licensed, так что, вероятно, стоит посмотреть.

Демонстрация: https://www.youtube.com/watch?v=yXZzzUEngiU

Шаговые отладчики

Не совсем модульное тестирование, но может помочь, если ваши тесты начнут давать сбой:

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

Моя собственная настройка QEMU + Buildroot + Python

Я также начал установку, сфокусированную на простоте разработки, но в итоге я добавил к ней также несколько простых возможностей тестирования: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508782827320209644dcbaf9a6b3141724#test-this -repo

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

Не очень просто автоматизировать тестирование ядра. Большинство разработчиков Linux проводят тестирование самостоятельно, так же, как упомянул adobriyan.

Однако есть несколько вещей, которые помогают отладить ядро ​​Linux:

• Kexec: системный вызов, который позволяет вам поместить другое ядро ​​в память и перезагрузиться, не возвращаясь в BIOS, и, в случае сбоя, перезагрузиться.
• dmesg: определенно место для поиска информации о том, что произошло во время загрузки ядра и работает ли оно / не работает.
• Инструментарий ядра: В дополнение к printk (и опции под названием 'CONFIG_PRINTK_TIME', которая позволяет вам видеть (с точностью до микросекунды), когда ядро ​​выводит что), конфигурация ядра позволяет вам включить МНОГО трассировщиков, которые позволяют им отлаживать то, что это происходит.

Затем разработчики обычно заставляют других проверять свои патчи. Как только исправления проверяются локально, и видно, что они ничему не мешают, и исправления проверяются на работу с последним ядром от Linus, ничего не нарушая, исправления отправляются в исходное состояние.

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

В дополнение к пунктам выше / ниже, в которых больше внимания уделяется тестированию функциональности, сертификации оборудования и тестированию производительности ядра Linux.

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

Разреженный - инструмент с открытым исходным кодом, предназначенный для поиска ошибок в ядре Linux.

Coccinelle - это еще одна программа, которая делает механизм сопоставления и преобразования, который предоставляет язык SmPL (Semantic Patch Language) для указания желаемых совпадений и преобразований в C-коде.

checkpatch.pl и другие скрипты - проблемы со стилем кодирования можно найти в файле Documentation / CodingStyle в дереве исходного кода ядра. При чтении важно помнить не то, что этот стиль чем-то лучше любого другого стиля, а то, что он последовательный. это помогает разработчикам легко находить и исправлять проблемы со стилем кодирования, был разработан скрипт scripts / checkpatch.pl в дереве исходного кода ядра. Этот сценарий может легко указывать на проблемы, и разработчик всегда должен запускать их изменения, вместо того, чтобы рецензент тратил свое время, указывая на проблемы позже.

Я предполагаю, что они используют виртуализацию для проведения быстрых тестов, например, QEMU, VirtualBox или Xen, и некоторые сценарии для выполнения конфигураций и автоматических тестов.

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

Там также есть:

MMTests - это набор тестов и сценариев для анализа результатов.

https://github.com/gormanm/mmtests

Trinity - системный тестер Linux

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

Также страницы LTP в sourceforge довольно устарели, и проект переехал на GitHub https://github.com/linux-test-project/ltp

Насколько я знаю, есть средство автоматической проверки регрессии производительности (с именем lkp / 0 day), работающее / финансируемое Intel, оно будет проверять каждый действительный патч, отправленный в список рассылки, и проверять оценки, измененные в различных микробенчмарках, таких как hackbench. , fio, unixbench, netperf и т. д., когда произойдет снижение / улучшение производительности, соответствующий отчет будет отправлен непосредственно автору патча и сопровождающим, связанным с Cc.

LTP и Memtests, как правило, являются предпочтительными инструментами.

Adobriyan упомянул цикл случайного тестирования сборки Ingo. Это в значительной степени покрывается 0-дневным тестовым ботом (он же тестовый бот kbuild). Хорошая статья об инфраструктуре представлена ​​здесь: сборка ядра / тестирование загрузки

Идея этой установки заключается в том, чтобы уведомить разработчиков как можно скорее, чтобы они могли достаточно быстро исправить ошибки. (до того, как исправления попадают в дерево Линуса в некоторых случаях, поскольку инфраструктура kbuild также проверяет деревья подсистемы сопровождающего)

Я выполнил компиляцию ядра Linux и сделал несколько Модификаций для Android (Marshmallow и Nougat), в которых я использую версию 3 Linux. Я сделал кросс-компиляцию в системе Linux, отладил ошибки вручную, а затем запустил файл загрузочного образа в Android и проверил, это происходило в лазейке или нет. Если он работает отлично, значит, он идеально скомпилирован в соответствии с требованиями системы.
Для компиляции ядра MotoG

ПРИМЕЧАНИЕ: - Ядро Linux будет меняться в соответствии с требованиями, которые зависят от системного оборудования.

Один раз после того, как участники предоставят свои файлы исправлений и после выполнения запроса на слияние, привратники Linux проверят исправление, интегрировав и проанализировав его. Как только он пройдет успешно, они объединят исправление с соответствующей веткой и выпустят новую версию. Тестовый проект Linux ( https://github.com/linux-test-project/ltp ) является основным источником, который предоставляет тестовые сценарии (тестовые случаи) для запуска на ядре после применения исправлений. Это может занять около 2 ~ 4 часов и зависит. Обратите внимание, что файловая система выбранного ядра будет проверяться. Пример: Ext4 генерирует разные результаты по сравнению с EXT3 и так далее.

Процедура тестирования ядра.

1. Получить последний исходный код ядра из хранилища. ( Https://www.kernel.org/ или Github.com)
2. Применить файл патча (используя инструмент Diff)
3. Сборка нового ядра.
4. Проверка на тестовые процедуры в LTP ( https://github.com/linux-test-project/ltp )