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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

Ответ 2

Естественно, что само ядро ​​и его части тестируются до выпуска, но эти тесты охватывают только базовые функции. Существуют некоторые системы тестирования, которые выполняют тестирование ядра 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) позволяет вводить ошибки и исключения в логику приложения для обеспечения более высокого охвата и отказоустойчивости системы.

Ответ 3

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

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

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

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

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

планы тестирования?

Нет.

Возможно, существует недоразумение, что есть центральный центр тестирования, и нет. Каждый делает то, что хочет.

Ответ 4

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

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

В v4.0 это приводит меня к:

Ядро 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 + Buildroot + Python

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

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

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

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

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

Ответ 7

Также есть:

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

https://github.com/gormanm/mmtests

Trinity, который является системным вызовом Fuzz для Linux

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

Ответ 11

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

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

Ответ 12

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

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