Як тестується ядро ​​Linux?

Як розробники Linux ядра випробовують свій код локально та після того, як вони це вчинили? Чи використовують вони якусь модульну перевірку, будують автоматизацію? тестові плани?

Ядро Linux має великий акцент на тестуванні спільноти.

Зазвичай будь-який розробник тестує свій власний код перед подачею, і досить часто вони будуть використовувати розробну версію ядра від Linus, або одне з інших нестабільних дерев / програм розвитку для проекту, що відповідає їх роботі. Це означає, що вони часто випробовують як свої зміни, так і зміни інших людей.

Офіційних планів тестування, як правило, не так багато, але можливо додаткове тестування, перш ніж об'єднати функції у верхівкові дерева.

Як зазначив Дін, є також деякі автоматизовані тестування, тестовий проект linux та автотест ядра ( хороший огляд ).

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

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

Природно, саме ядро ​​та його частини тестуються до випуску, але ці тести охоплюють лише основні функціональні можливості. Існує декілька систем тестування, які виконують тестування ядра 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 Kernel

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

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

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

У класичному сенсі слів немає.

E. g. Ingo Molnar виконує наступне навантаження: 1. створити нове ядро ​​зі випадковим набором параметрів конфігурації 2. завантажитися в нього 3. goto 1

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

тестові плани?

Немає.

Може виникнути непорозуміння, що там є центральний випробувальний центр, його немає. Кожен робить те, що хоче.

Деревні інструменти

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

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

У v4.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?
  • coccicheckдля кокцинели (згадується askb )

Ядро CI

https://kernelci.org/ - це проект, який має на меті зробити тестування ядра більш автоматизованим і помітним.

Схоже, це лише тести для складання та завантаження (TODO, як автоматично перевірити, чи працював завантажувач Source), за адресою https://github.com/kernelci/ ).

Linaro, здається, є головним підтримувачем проекту, за участю багатьох великих компаній: https://kernelci.org/sponsors/

Лінаро Лава

http://www.linaro.org/initiatives/lava/ виглядає як система CI з акцентом на підключення дошки розвитку та ядро ​​Linux.

ARM LISA

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

Не впевнений, що це робить докладно, але це ARM та Apache Licensed, тому, ймовірно, варто подивитися.

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

Крок налагоджувачів

Насправді не тестування одиниць, але може допомогти, коли ваші тести почнуть виходити з ладу:

• QEMU + GDB: https://stackoverflow.com/a/42316607/895245
• КГДБ: https://stackoverflow.com/a/44226360/895245

Моя власна програма QEMU + Buildroot + Python

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

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

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

Однак є кілька речей, які допомагають налагодити ядро ​​Linux:

• kexec: системний виклик, який дозволяє помістити інше ядро ​​в пам'ять і перезавантажити, не повертаючись до BIOS, і якщо воно не вдалося, перезавантажте назад.
• dmesg: Однозначно місце шукати інформацію про те, що сталося під час завантаження ядра та чи працює воно / не працює.
• Інструментація ядра: Окрім printk's (та опції під назвою "CONFIG_PRINTK_TIME", яка дозволяє бачити (з точністю до мікросекунди), коли ядро ​​виводить що), конфігурація ядра дозволяє увімкнути багато трасерів, які дозволять їм налагоджувати те, що стається.

Потім розробники, як правило, інші рецензують свої виправлення. Після того, як патчі будуть переглянуті локально і помічено, що вони не заважають нічому іншому, а патчі проходять тест на роботу з останнім ядром від Linus, не порушуючи нічого, патчі висуваються вгору за течією.

Редагувати: Ось приємне відео, в якому детально описується процес, через який патч проходить, перш ніж його інтегрувати в ядро.

На додаток до вище / нижче пунктів, які акцентують увагу більше на тестуванні функціональності, тестуванні апаратної сертифікації та тестуванні продуктивності Linux ядра.

Багато тестувань насправді відбувається через насправді сценарії, інструменти аналізу статичного коду, огляди коду тощо. Це дуже ефективно в лові помилок, які в іншому випадку можуть щось зламати в додатку.

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

Coccinelle - це ще одна програма, що забезпечує механізм узгодження та перетворення, що забезпечує мову SmPL (Semantic Patch Language) для визначення бажаних відповідностей та перетворень у коді С.

checkpatch.pl та інші сценарії - проблеми стилю кодування можна знайти у файлі Documentation / CodingStyle у дереві джерела ядра. Важливо пам’ятати, читаючи не те, що цей стиль якось кращий за будь-який інший стиль, а лише те, що він є послідовним. це допомагає розробникам легко знаходити та виправляти проблеми стилю кодування, розроблений сценарій сценарію / checkpatch.pl у дереві джерела ядра. Цей скрипт може легко вказати на проблеми, і його завжди повинен виконувати розробник на свої зміни, замість того, щоб рецензент витрачав свій час, вказуючи на проблеми пізніше.

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

Автоматизоване тестування, ймовірно, робиться шляхом випробування або багатьох випадкових конфігурацій, або декількох конкретних (якщо вони працюють з певною проблемою). У Linux є багато інструментів низького рівня (наприклад, dmesg) для моніторингу та реєстрації даних про налагодження з ядра, тому я думаю, що він також використовується.

Є також:

MMTests - це збірка орієнтирів та сценаріїв для аналізу результатів

https://github.com/gormanm/mmtests

Трійця, яка є системою тестування викликів системи Linux

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

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

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

LTP і Memtests - це, як правило, переважні інструменти.

adobriyan згадав цикл тестування побудови випадкової конфігурації Інго. Це майже зараз охоплене 0-денним тестовим ботом (він же kbuild test bot). Тут представлена ​​приємна стаття про інфраструктуру: Тестування ядра / завантаження

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

Я зробив компіляцію ядра Linux і зробив декілька модифікацій для android (Marshmallow і Nougat), в яких я використовую версію Linux 3. Я перекреслив її в системі 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 )