Kernel

De Linux kernel is een zeer belangrijk onderdeel van de software op bijna elk Android toestel. Dit gedeelte beschrijft Linux kernel ontwikkeling en releasemodellen (hieronder), stabiele en lang-termsupported (LTS) kernels (inclusief waarom alle Android-toestellen stabiele releases zouden moeten gebruiken in plaats van cherry picking patches), kernelconfiguratie en -verharding, vereisten voor interfaces en themodulaire kernels (geïntroduceerd in Android O), kerneldebugging en netwerktesten, en SquashFS.

Linux kernel ontwikkeling

De Linux kernel is het grootste collaboratieve softwareproject ooit. In 2016 droegen meer dan 4.000 verschillende ontwikkelaars van meer dan 450 verschillende bedrijven bij aan het project en waren er 6 releases, die elk tussen de 12.000 en 16.000 verschillende wijzigingen bevatten. Eind 2016 was de omvang van de Linux-kernel iets meer dan56 duizend bestanden, bestaande uit 22 miljoen regels code, build scripts, en documentatie (kernel release 4.9). (Voor volledige statistieken over de ontwikkeling van Linux, ziehttps://kernelnewbies.org/DevelopmentStatistics.)

Hoewel de Linux-kernel code bevat voor alle verschillende chiparchitecturen en hardwaredrivers die het ondersteunt, draait een individueel systeem slechts een fractie van de codebase. Een gemiddelde laptop gebruikt ongeveer 2 miljoen regels kernelcode uit 5.000 bestanden om goed te functioneren, terwijl de Pixel-telefoon 3,2 miljoen regels kernelcode uit 6.000 bestanden gebruikt (vanwege de toegenomen complexiteit van een SoC).

Linux kernel-releases

De Linux-kernel gebruikt een releasemodel dat wezenlijk verschilt van de standaard AOSP-releases. Met de release van de 2.6 kernel in december 2003, stapte de kernel ontwikkelaarsgemeenschap over van het vorige model van een aparte ontwikkel- en stabiele kernel branch, en ging over op een stableonly branch model. In dit model kwam er elke 2 tot 3 maanden een nieuwe release, en die release werd stabiel verklaard en aanbevolen voor alle gebruikers om te draaien. Deze verandering in het ontwikkelmodel was het gevolg van de zeer lange releasecyclus voorafgaand aan de 2.6 kernel (bijna 3 jaar), en de strijd om twee verschillende takken van de codebase tegelijkertijd te onderhouden.

De nummering van de kernelreleases begon bij 2.6.x, waarbij x een oplopend nummer was dat bij elke release veranderde (de waarde van het nummer heeft geen betekenis, behalve dat het nieuwer is dan de vorige kernelrelease). De kernelversie is sindsdien opgeschoven naar 4.x, goed voor 2 grote versiewijzigingen.Deze versienummers zijn alleen gekozen door de beheerder(s) om verwarring onder gebruikers te voorkomen, veroorzaakt door hogere minor release nummers.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.