it-swarm.com.ru

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

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

242
Ashkan Kh. Nazary

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

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

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

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

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

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

69
JosephH

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

Тестовый проект Linux (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) позволяет внедрять ошибки и исключения в логику приложения для достижения более высокого охвата и отказоустойчивости системы.

65
Karen Tsirunyan

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

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

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

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

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

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

Нет.

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

56
adobriyan

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

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

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

CI ядра

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

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

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

Линаро Лава

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

ARM Лиза

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

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

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

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

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

Мой собственный QEMU + Buildroot + Python setup

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

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

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

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

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

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

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

13
Vanwaril

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

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

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

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

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

6
askb

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

MMTests который представляет собой набор тестов и сценариев для анализа результатов

https://github.com/gormanm/mmtests

Троица который является системным вызовом Linux Fuzz Tester

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

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

3
metan

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

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

2
emcee

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

1
Yu Chen

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

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

0
Vineet Jain

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

0
Pradeep Goswami

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

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

0
krisharav