Jak testowane jest jądro Linux?

W jaki sposób programiści jądra Linux testują swój kod lokalnie i po jego zatwierdzeniu? Czy używają jakiegoś rodzaju testów jednostkowych, budują automatyzację? plany testowe?

Jądro linuksa kładzie duży nacisk na testy społeczności.

Zazwyczaj każdy programista testuje swój kod przed przesłaniem, i dość często korzysta z wersji rozwojowej jądra Linusa lub jednego z innych niestabilnych / programistycznych drzew do projektu odpowiedniego dla ich pracy. Oznacza to, że często testują zarówno swoje zmiany, jak i zmiany innych osób.

Formalne plany testów zwykle nie przeszkadzają, ale można poprosić o dodatkowe testy, zanim funkcje zostaną scalone z wcześniejszymi drzewami.

Jak zauważył Dean, są też pewne automatyczne testy, projekt testu linux i autotest jądra ( dobry przegląd ).

Programiści często piszą również automatyczne testy ukierunkowane na testowanie ich zmian, ale nie jestem pewien, czy istnieje (często stosowany) mechanizm do centralnego gromadzenia tych testów adhoc.

To zależy w dużej mierze od tego, który obszar jądra jest zmieniany - testowanie nowego sterownika sieciowego jest zupełnie inne niż testowanie przy zastępowaniu podstawowego algorytmu planowania.

Oczywiście samo jądro i jego części są testowane przed wydaniem, ale testy te obejmują jedynie podstawową funkcjonalność. Istnieje kilka systemów testujących, które przeprowadzają testy jądra Linux:

Linux Test Project (LTP) dostarcza pakiety testowe dla społeczności open source, które sprawdzają niezawodność i stabilność Linuksa. Zestaw testowy LTP zawiera zbiór narzędzi do testowania jądra Linux i powiązanych funkcji. https://github.com/linux-test-project/ltp

Autotest - platforma do w pełni zautomatyzowanych testów. Jest przeznaczony przede wszystkim do testowania jądra Linuksa, chociaż jest przydatny do wielu innych celów, takich jak kwalifikowanie nowego sprzętu, testowanie wirtualizacji i inne ogólne testowanie programów przestrzeni użytkownika na platformach Linux. Jest to projekt typu open source na licencji GPL i jest wykorzystywany i rozwijany przez wiele organizacji, w tym Google, IBM, Red Hat i wiele innych. http://autotest.github.io/

Istnieją również systemy certyfikacji opracowane przez niektóre duże firmy dystrybucyjne GNU / Linux. Systemy te zwykle sprawdzają pełną dystrybucję GNU / Linux pod kątem zgodności ze sprzętem. Istnieją systemy certyfikacji opracowane przez Novell, Red Hat, Oracle, Canonical, Google .

Istnieją również systemy do dynamicznej analizy jądra Linux:

Kmemleak to wykrywacz wycieków pamięci zawarty w jądrze Linuksa. Zapewnia sposób na wykrycie ewentualnych wycieków pamięci jądra w sposób podobny do śledzenia zbieracza śmieci, z tą różnicą, że obiekty osierocone nie są zwalniane, ale zgłaszane tylko przez / sys / kernel / debug / kmemleak.

Kmemcheck przechwytuje każdy odczyt i zapis do pamięci przydzielonej dynamicznie (tj. Za pomocą kmalloc ()). Jeśli zostanie odczytany adres pamięci, który nie został wcześniej zapisany, komunikat zostanie wydrukowany w dzienniku jądra. Jest także częścią jądra Linux

Fault Injection Framework (zawarty w jądrze Linuksa) pozwala na wprowadzanie błędów i wyjątków do logiki aplikacji w celu uzyskania większego zasięgu i odporności systemu na błędy.

W jaki sposób programiści jądra Linux testują swój kod lokalnie i po jego zatwierdzeniu?

Czy używają jakiegoś rodzaju testów jednostkowych, budują automatyzację?

W klasycznym znaczeniu tego słowa nie.

Np. Ingo Molnar uruchamia następujące obciążenie: 1. zbuduj nowe jądro z losowym zestawem opcji konfiguracji 2. uruchom go 3. goto 1

Rozpatrywane jest każde ostrzeżenie dotyczące kompilacji, niepowodzenia rozruchu, BŁĘDU lub środowiska wykonawczego. 24/7. Pomnóż przez kilka pól, a można odkryć całkiem sporo problemów.

plany testowe?

Nie.

Może być nieporozumienie, że istnieje centralny ośrodek testowy, nie ma go. Każdy robi, co chce.

Narzędzia w drzewie

Dobrym sposobem na znalezienie narzędzi testowych w jądrze jest:

• make help i przeczytaj wszystkie cele
• zajrzyj pod narzędzia / testy

W wersji 4.0 prowadzi mnie to do:

• kselftest w ramach narzędzi / testów / autotestów . Uruchom z make kselftest. Musi już działać wbudowane jądro. Zobacz także: Dokumentacja / kselftest.txt , https://kselftest.wiki.kernel.org/

• ktest w ramach narzędzi / testów / ktest . Zobacz także: http://elinux.org/Ktest , http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest

• Sekcja analizatorów statycznychmake help , która zawiera cele takie jak:

  • checkstack: Perl: co robi checkstack.pl w systemie Linux?
  • coccicheckdla Coccinelle (wspomniane przez askb )

Jądro CI

https://kernelci.org/ to projekt, którego celem jest zwiększenie automatyzacji i widoczności testów jądra.

Wydaje się, że wykonuje tylko testy kompilacji i rozruchu (TODO, jak automatycznie przetestować, czy rozruch działał. Źródło powinno znajdować się na https://github.com/kernelci/ ).

Wydaje się, że Linaro jest głównym opiekunem projektu, przy wsparciu wielu dużych firm: https://kernelci.org/sponsors/

Linaro Lava

http://www.linaro.org/init inicjatyw/lava/ wygląda jak system CI skupiający się na debugowaniu płyt programistycznych i jądrze Linuksa.

ARM LISA

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

Nie jestem pewien, co dokładnie robi, ale jest to licencjonowane przez ARM i Apache, więc prawdopodobnie warto to sprawdzić.

Demo: https://www.youtube.com/watch?v=yXZzzUEngiU

Debugery krokowe

Naprawdę nie testowanie jednostkowe, ale może pomóc, gdy testy zaczną się nie powieść:

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

Moja własna konfiguracja QEMU + Buildroot + Python

Rozpocząłem także konfigurację skoncentrowaną na łatwości programowania, ale ostatecznie dodałem do niej również kilka prostych funkcji testowych: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508782827320209644dcbaf9a6b3141724#test-this -repo

Nie przeanalizowałem szczegółowo wszystkich innych konfiguracji i prawdopodobnie robią one znacznie więcej niż moje, ale uważam, że moja konfiguracja jest bardzo łatwa do rozpoczęcia, ponieważ ma dużo dokumentacji i automatyzacji.

Zautomatyzowanie testowania jądra nie jest łatwe. Większość programistów Linuksa wykonuje testy na własną rękę, podobnie jak wspomniano o adobriyan.

Jest jednak kilka rzeczy, które pomagają w debugowaniu jądra Linux:

• kexec: Wywołanie systemowe, które pozwala umieścić inne jądro w pamięci i zrestartować komputer bez powrotu do BIOS-u, a jeśli się nie powiedzie, uruchom ponownie komputer.
• dmesg: Zdecydowanie miejsce do szukania informacji o tym, co wydarzyło się podczas uruchamiania jądra i czy działa / nie działa.
• Oprzyrządowanie jądra: Oprócz printk's (i opcji o nazwie „CONFIG_PRINTK_TIME”, która pozwala zobaczyć (z dokładnością do mikrosekund), kiedy wyjście jądra co), konfiguracja jądra pozwala na włączenie DUŻO znaczników, które pozwalają im debugować co dzieje się.

Następnie programiści zwykle proszą innych użytkowników o sprawdzenie poprawek. Gdy łatki są sprawdzane lokalnie i nie kolidują z niczym innym, a łatki są testowane pod kątem działania z najnowszym jądrem Linusa bez niszczenia czegokolwiek, łatki są wypychane w górę.

Edycja: Oto fajne wideo przedstawiające proces, przez który łatka przechodzi, zanim zostanie zintegrowana z jądrem.

Oprócz punktów powyżej / poniżej, które kładą większy nacisk na testowanie funkcjonalności, testowanie certyfikacji sprzętu i testowanie wydajności jądra Linux.

Wiele testów faktycznie się dzieje, w rzeczywistości skrypty, narzędzia do analizy kodu statycznego, recenzje kodu itp., Które są bardzo skuteczne w wykrywaniu błędów, które w przeciwnym razie mogłyby popsuć coś w aplikacji.

Rzadkie - narzędzie typu open source przeznaczone do znajdowania błędów w jądrze Linux.

Coccinelle to inny program obsługujący silnik dopasowywania i transformacji, który udostępnia język SmPL (Semantic Patch Language) do określania pożądanych dopasowań i transformacji w kodzie C.

checkpatch.pl i inne skrypty - problemy ze stylem kodowania można znaleźć w pliku Documentation / CodingStyle w drzewie źródeł jądra. Ważną rzeczą do zapamiętania podczas czytania nie jest to, że ten styl jest jakoś lepszy niż jakikolwiek inny styl, tylko że jest spójny. pomaga to deweloperom łatwo znaleźć i naprawić problemy ze stylem kodowania, opracowano skrypty skryptowe / checkpatch.pl w drzewie źródeł jądra. Ten skrypt może łatwo wskazywać problemy i zawsze powinien być uruchamiany przez programistę po wprowadzonych zmianach, zamiast zmuszać recenzenta do marnowania czasu na wskazywanie problemów później.

Wyobrażam sobie, że używają wirtualizacji do przeprowadzania szybkich testów, takich jak QEMU, VirtualBox lub Xen oraz niektórych skryptów do wykonywania konfiguracji i testów automatycznych.

Zautomatyzowane testowanie odbywa się prawdopodobnie przez wypróbowanie wielu losowych konfiguracji lub kilku konkretnych konfiguracji (jeśli działają one z konkretnym problemem). Linux ma wiele narzędzi niskiego poziomu (takich jak dmesg) do monitorowania i rejestrowania danych debugowania z jądra, więc wyobrażam sobie, że to również jest używane.

Istnieją również:

MMTest, który jest zbiorem testów porównawczych i skryptów do analizy wyników

https://github.com/gormanm/mmtests

Trinity, która jest testerem fuzz systemu Linux

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

Również strony LTP w sourceforge są dość przestarzałe, a projekt został przeniesiony do GitHub https://github.com/linux-test-project/ltp

O ile mi wiadomo, narzędzie Intel automatycznie sprawdza regresję wydajności (o nazwie lkp / 0 dzień), przetestuje każdą poprawną poprawkę wysłaną na listę mailingową i sprawdzi wyniki zmienione w stosunku do różnych znaków mikrodruku, takich jak hackbench , fio, unixbench, netperf itp., gdy nastąpi regresja / poprawa wydajności, odpowiedni raport zostanie wysłany bezpośrednio do autora łatki i opiekunów powiązanych z CC.

LTP i memtesty są ogólnie preferowanymi narzędziami.

adobriyan wspomniał o testach kompilacji losowej konfiguracji Ingo. Jest to w zasadzie objęte przez 0-dniowego bota testowego (inaczej bota testowego kbuild). Miły artykuł o infrastrukturze przedstawiono tutaj: Testowanie kompilacji / rozruchu jądra

Ideą tej konfiguracji jest jak najszybsze powiadomienie programistów, aby mogli oni wkrótce naprawić błędy. (zanim łaty trafią do drzewa Linusa w niektórych przypadkach, ponieważ infrastruktura kbuild testuje również drzewa podsystemów opiekuna)

Zrobiłem kompilację jądra Linuksa i wprowadziłem kilka modyfikacji dla Androida (Marshmallow i Nougat), w których używam Linuksa w wersji 3. Skompilowałem go w systemie Linux, ręcznie debugowałem błędy, a następnie uruchomiłem plik obrazu rozruchowego w Androidzie i sprawdziłem, czy szło w pętlę, czy nie. Jeśli działa idealnie, oznacza to, że jest idealnie skompilowany zgodnie z wymaganiami systemowymi.
Do kompilacji jądra MotoG

UWAGA: - Jądro Linux zmieni się zgodnie z wymaganiami zależnymi od sprzętu systemowego

Raz po tym, jak współtwórcy prześlą swoje pliki łatek i po zgłoszeniu żądania scalenia, strażnicy linuxa sprawdzają łatkę poprzez jej zintegrowanie i przejrzenie, a jeśli się powiedzie, połączą łatę z odpowiednią gałęzią i wydadzą nową wersję. Linux Test Project ( https://github.com/linux-test-project/ltp ) jest głównym źródłem, które udostępnia scenariusze testowe (przypadki testowe) do uruchomienia na jądrze po zastosowaniu poprawek. Może to potrwać około 2 ~ 4 godzin i zależy. Pamiętaj, że system plików wybranego jądra będzie testował. Ex: Ext4 generuje różne wyniki w porównaniu z EXT3 i tak dalej.

Procedura testowania jądra.

1. Pobierz najnowsze źródło jądra z repozytorium. ( Https://www.kernel.org/ lub Github.com)
2. Zastosuj plik łatki (za pomocą narzędzia Diff)
3. Zbuduj nowe jądro.
4. Testuj procedury testowe w LTP ( https://github.com/linux-test-project/ltp )