Hoe wordt de Linux-kernel getest?

Hoe testen de Linux-kernelontwikkelaars hun code lokaal en nadat ze deze hebben vastgelegd? Gebruiken ze een soort unit-testing, build-automatisering? test plannen?

Antwoord 1, autoriteit 100%

De Linux-kernel legt veel nadruk op het testen van de gemeenschap.

Normaal gesproken zal elke ontwikkelaar zijn eigen code testen voordat hij deze indient, en vrij vaak zullen ze een ontwikkelingsversie van de kernel van Linus gebruiken, of een van de andere onstabiele/ontwikkelstructuren voor een project dat relevant is voor hun werk. Dit betekent dat ze vaak zowel hun wijzigingen als die van anderen testen.

Er zijn meestal niet veel formele testplannen, maar er kan om extra tests worden gevraagd voordat functies worden samengevoegd in stroomopwaartse bomen.

Zoals Dean opmerkte, zijn er ook enkele geautomatiseerde tests, het linux-testprojecten de kernel autotest(goed overzicht).

Ontwikkelaars schrijven vaak ook geautomatiseerde tests om hun wijziging te testen, maar ik weet niet zeker of er een (vaak gebruikt) mechanisme is om deze ad-hoctests centraal te verzamelen.

Het hangt natuurlijk sterk af van welk gebied van de kernel wordt gewijzigd – het testen dat je zou doen voor een nieuwe netwerkdriver is heel anders dan het testen dat je zou doen bij het vervangen van het kernplanningsalgoritme.

Antwoord 2, autoriteit 84%

Natuurlijk worden de kernel zelf en zijn onderdelen voorafgaand aan de release getest, maar deze tests hebben alleen betrekking op de basisfunctionaliteit. Er zijn enkele testsystemen die de Linux-kernel testen:

Het Linux Test Project (LTP)levert testsuites aan de open source-gemeenschap die de betrouwbaarheid en stabiliteit van Linux valideren. De LTP-testsuite bevat een verzameling tools voor het testen van de Linux-kernel en gerelateerde functies. https://github.com/linux-test-project/ltp

Autotest— een raamwerk voor volledig geautomatiseerd testen. Het is in de eerste plaats ontworpen om de Linux-kernel te testen, hoewel het ook nuttig is voor veel andere doeleinden, zoals het kwalificeren van nieuwe hardware, virtualisatietests en andere algemene tests van gebruikersruimteprogramma’s onder Linux-platforms. Het is een open-sourceproject onder de GPL en wordt gebruikt en ontwikkeld door een aantal organisaties, waaronder Google, IBM, Red Hat en vele anderen. http://autotest.github.io/

Er zijn ook certificeringssystemen ontwikkeld door enkele grote GNU/Linux-distributiebedrijven. Deze systemen controleren meestal volledige GNU/Linux-distributies op compatibiliteit met hardware. Er zijn certificeringssystemen ontwikkeld door Novell, Red Hat, Oracle, Canonical, Google.

Er zijn ook systemen voor dynamische analyse van de Linux-kernel:

Kmemleakis een geheugenlekdetector die is opgenomen in de Linux-kernel. Het biedt een manier om mogelijke kernelgeheugenlekken te detecteren op een manier die vergelijkbaar is met een tracerende garbage collector, met het verschil dat de weesobjecten niet worden vrijgegeven, maar alleen worden gerapporteerd via /sys/kernel/debug/kmemleak.

Kmemcheckvangt elke lees- en schrijfactie op die dynamisch is toegewezen (d.w.z. met kmalloc()). Als een geheugenadres wordt gelezen waar nog niet eerder naar is geschreven, wordt een bericht afgedrukt naar het kernellogboek. Is ook een onderdeel van Linux Kernel

Fault Injection Framework(inbegrepen in de Linux-kernel) maakt het mogelijk om fouten en uitzonderingen toe te voegen aan de logica van een applicatie om een ​​hogere dekking en fouttolerantie van het systeem te bereiken.

Antwoord 3, autoriteit 77%

Hoe testen de Linux-kernelontwikkelaars hun code lokaal en nadat ze deze hebben vastgelegd?

Gebruiken ze een soort unit-testing, build-automatisering?

In de klassieke zin van het woord, nee.

E. G. Ingo Molnar voert de volgende werklast uit:
1. bouw een nieuwe kernel met een willekeurige set configuratie-opties
2. boot erin
3. ga naar 1

Elke build-, boot-, BUG- of runtime-waarschuwing wordt aangepakt. 24/7.
Vermenigvuldig met meerdere vakjes, en je kunt heel wat problemen ontdekken.

testplannen?

Nee.

Er kan een misverstand zijn dat er een centrale testfaciliteit is, maar die is er niet.
Iedereen doet wat hij wil.

4, Autoriteit 7%

In aanvulling op hierboven / onder punten, welke nadruk ligt op de functionaliteitstests, hardwarecertificeringstests en prestaties die de Linux-kernel testen.

Veel een stuk een testen gebeurt daadwerkelijk door, daadwerkelijk scripts, statische codeanalysetools, code Reviews etc. die zeer efficiënt is bij het vangen van bugs, die anders iets in de applicatie zou breken.

spaarzaam – een open-source tool ontworpen om fouten in de Linux-kernel te vinden.

Coccinelle is een ander programma doet overeenkomende en transformatiemotor die de taal SMPL (Semantic Patch Language) biedt voor het opgeven van Gewenste overeenkomsten en transformaties in C-code.

Checkpatch.pl en andere scripts – Coding Style-problemen is te vinden in de bestandsdocumentatie / coderingstijl in de kernelbronboom. Het belangrijkste om te onthouden tijdens het lezen is niet dat deze stijl op de een of andere manier beter is dan elke andere stijl, alleen dat het consistent is. Dit helpt ontwikkelaars gemakkelijk coderenstijl-problemen te vinden en op te lossen, de scriptscripts / checkpatch.pl in de kernelbron is ontwikkeld. Dit script kan gemakkelijk aangeven, en moet altijd worden gerund door een ontwikkelaar op hun wijzigingen, in plaats van een recensent te hebben verspilt hun tijd door later op problemen te wijzen.

5, Autoriteit 5%

Er zijn ook:

MMTESTS die verzameling benchmarks en scripts is om de resultaten