Linux çekirdeği nasıl test edilir?

Linux çekirdek geliştiricileri kodlarını yerel olarak ve işledikten sonra nasıl test eder? Bir tür birim testi kullanıyorlar mı, otomasyon kuruyorlar mı? test planları?

Linux çekirdeği topluluk testlerine büyük önem vermektedir.

Tipik olarak herhangi bir geliştirici göndermeden önce kendi kodunu test eder ve çoğu zaman Linus'un çekirdeğinin geliştirme sürümünü veya çalışmalarıyla ilgili bir proje için diğer kararsız / geliştirme ağaçlarından birini kullanır. Bu, genellikle hem değişikliklerini hem de diğer insanların değişikliklerini test ettikleri anlamına gelir.

Resmi test planlarının yolunda çok fazla olma eğilimi yoktur, ancak özellikler yukarı akış ağaçlarıyla birleştirilmeden önce ekstra test istenebilir.

Dean'in işaret ettiği gibi, bazı otomatik testler, linux test projesi ve çekirdek otomatik testi ( iyi genel bakış ) da var.

Geliştiriciler de genellikle değişikliklerini test etmeyi hedefleyen otomatik testler yazacaklar, ancak bu adhoc testleri merkezi olarak toplamak için (genellikle kullanılan) bir mekanizma olduğundan emin değilim.

Tabii ki çekirdeğin hangi alanının değiştirildiğine çok bağlıdır - yeni bir ağ sürücüsü için yapacağınız test, çekirdek zamanlama algoritmasını değiştirirken yapacağınız testten oldukça farklıdır.

Doğal olarak, çekirdeğin kendisi ve parçaları serbest bırakılmadan önce test edilir, ancak bu testler sadece temel işlevselliği kapsar. Linux Çekirdeği testi yapan bazı test sistemleri vardır:

Linux Test Projesi (LTP) , Linux'un güvenilirliğini ve kararlılığını doğrulayan açık kaynak topluluğuna test paketleri sunar. LTP test paketi, Linux çekirdeğini ve ilgili özellikleri test etmek için bir dizi araç içerir. https://github.com/linux-test-project/ltp

Autotest - tam otomatik test için bir çerçeve. Öncelikle Linux çekirdeğini test etmek için tasarlanmıştır, ancak yeni donanım, sanallaştırma testi ve Linux platformları altında diğer genel kullanıcı alanı programı testi gibi diğer birçok amaç için yararlıdır. GPL kapsamında açık kaynaklı bir projedir ve Google, IBM, Red Hat ve diğerleri de dahil olmak üzere birçok kuruluş tarafından kullanılır ve geliştirilir.http://autotest.github.io/

Ayrıca bazı büyük GNU / Linux dağıtım şirketleri tarafından geliştirilen sertifikasyon sistemleri bulunmaktadır. Bu sistemler genellikle eksiksiz GNU / Linux dağıtımlarının donanımla uyumluluğunu kontrol eder. Novell, Red Hat, Oracle, Canonical, Google tarafından geliştirilen sertifika sistemleri vardır. .

Linux çekirdeğinin dinamik analizi için sistemler de vardır:

Kmemleak , Linux çekirdeğinde bulunan bir bellek sızıntı detektörüdür. Olası çekirdek bellek sızıntılarını, izleme çöp toplayıcısına benzer şekilde, yetim nesnelerinin serbest bırakılmadığı, yalnızca / sys / kernel / debug / kmemleak ile bildirildiği farkıyla tespit etmenin bir yolunu sunar.

Kmemcheck , dinamik olarak ayrılan her okuma ve yazma belleğini yakalar (yani kmalloc () ile). Daha önce yazılmamış bir bellek adresi okunursa, çekirdek günlüğüne bir mesaj yazdırılır. Ayrıca Linux Çekirdeğinin bir parçasıdır

Arıza Enjeksiyonu Çerçevesi (Linux çekirdeğinde bulunur), sistemin daha yüksek kapsama alanına ve hataya toleransını elde etmek için bir uygulamanın mantığına hata ve istisnalar aşılamaya izin verir.

Linux çekirdek geliştiricileri kodlarını yerel olarak ve işledikten sonra nasıl test eder?

Bir tür birim testi kullanıyorlar mı, otomasyon kuruyorlar mı?

Klasik anlamda, hayır.

Örneğin. Ingo Molnar aşağıdaki iş yükünü çalıştırıyor: 1. rasgele yapılandırma seçenekleri kümesiyle yeni bir çekirdek oluşturun 2. içine önyükleme 3. git 1

Her derleme başarısız, önyükleme başarısız, HATA veya çalışma zamanı uyarısı ele alınır. 24/7. Birkaç kutu ile çarpın ve biri oldukça fazla sorunu ortaya çıkarabilir.

test planları?

Hayır.

Merkezi test tesisinin olduğu konusunda yanlış anlaşılmalar olabilir, yoktur. Herkes istediğini yapar.

Ağaç içi araçlar

Çekirdekteki test araçlarını bulmanın iyi bir yolu:

• make help ve tüm hedefleri oku
• araçların / testlerin altına bakın

V4.0 sürümünde, bu beni:

• araçlar / test / selftests altında kselftest . İle çalıştırın make kselftest. Zaten inşa edilmiş bir çekirdek çalıştırıyor olmalı. Ayrıca bkz: Documentation / kselftest.txt , https://kselftest.wiki.kernel.org/

• araçlar / test / ktest altında ktest . Ayrıca bkz: http://elinux.org/Ktest , http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest

• make helpGibi hedefleri içeren statik analizörler bölümü :

  • checkstack: Perl: Linux kaynağında checkstack.pl ne yapıyor?
  • coccicheckCoccinelle için ( askb tarafından bahsedilen )

Çekirdek CI

https://kernelci.org/ , çekirdek testini daha otomatik ve görünür hale getirmeyi amaçlayan bir projedir.

Sadece derleme ve önyükleme testleri yapıyor gibi görünüyor (TODO, önyüklemenin çalıştığını otomatik olarak nasıl test eder? Kaynak https://github.com/kernelci/ olmalıdır ).

Linaro , birçok büyük şirketin katkılarıyla projenin ana sorumlusu gibi görünüyor: https://kernelci.org/sponsors/

Linaro Lava

http://www.linaro.org/initiferences/lava/ , geliştirme kurulu getirisine ve Linux çekirdeğine odaklanan bir CI sistemine benziyor.

ARM LISA

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

Ayrıntılı olarak ne yaptığından emin değilim, ancak ARM ve Apache Lisanslı, bu yüzden muhtemelen bir göz atmaya değer.

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

Adım ayıklayıcıları

Gerçekten birim testi değil, testleriniz başarısız olmaya başladıktan sonra yardımcı olabilir:

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

Kendi QEMU + Buildroot + Python kurulumum

Ayrıca, geliştirme kolaylığına odaklanan bir kurulum başlattım, ancak buna basit test yetenekleri de ekledim: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508782827320209644dcbaf9a6b3141724#test-this -repo

Diğer tüm kurulumları ayrıntılı olarak analiz etmedim ve muhtemelen benimkinden çok daha fazlasını yapıyorlar, ancak kurulumumun hızlı bir şekilde başlamak için çok kolay olduğuna inanıyorum çünkü çok fazla dokümantasyon ve otomasyona sahip.

Çekirdek testlerini otomatikleştirmek çok kolay değil. Linux geliştiricilerinin çoğu testi adobriyan'da olduğu gibi kendi başlarına yapar.

Bununla birlikte, Linux Çekirdeğinin hata ayıklamasına yardımcı olan birkaç şey vardır:

• kexec: Başka bir çekirdeği belleğe koymanıza ve BIOS'a geri dönmeden yeniden başlatmanıza ve başarısız olursa yeniden başlatmanıza izin veren bir sistem çağrısı.
• dmesg: Kesinlikle çekirdek önyüklemesi sırasında neler olduğu ve çalışıp çalışmadığı / çalışmadığı hakkında bilgi aramak için bir yer.
• Çekirdek Enstrümantasyonu: Printk'e (ve 'CONFIG_PRINTK_TIME') adı verilen ve çekirdek çıktısının ne olduğunu görmenize (mikrosaniye doğruluğuna) izin veren bir seçeneğe ek olarak, çekirdek yapılandırması, oluyor.

Ardından, geliştiriciler genellikle başkalarını yamalarını gözden geçirir. Yamalar yerel olarak incelendiğinde ve başka hiçbir şeye müdahale etmediği görüldüğünde ve yamalar hiçbir şey kırmadan Linus'un en son çekirdeği ile çalışacak şekilde test edilir, yamalar yukarı doğru itilir.

Düzenleme: İşte bir düzeltme eki çekirdeğe entegre edilmeden önce geçen süreci detaylandıran güzel bir video .

Linux çekirdeğinin işlev testine, donanım sertifikasyon testine ve performans testine daha fazla vurgu yapan yukarıdaki / aşağıdaki noktalara ek olarak.

Aslında bir test gerçekten gerçekleşir, aslında komut dosyaları, statik kod analiz araçları, kod incelemeleri vb. Bu hataların yakalanmasında çok etkilidir, aksi takdirde uygulamada bir şey kırır.

Sparse - Linux çekirdeğindeki hataları bulmak için tasarlanmış açık kaynaklı bir araçtır.

Coccinelle , C kodunda istenen eşleşmeleri ve dönüşümleri belirtmek için SmPL (Semantik Yama Dili) dilini sağlayan bir eşleştirme ve dönüştürme motorudur.

checkpatch.pl ve diğer komut dosyaları - kodlama stili sorunları, çekirdek kaynak ağacındaki Documentation / CodingStyle dosyasında bulunabilir. Okurken hatırlanması gereken önemli şey, bu stilin diğer stillerden bir şekilde daha iyi olması değil, sadece tutarlı olmasıdır. Bu, geliştiricilerin kodlama stili sorunlarını kolayca bulmasına ve düzeltmesine yardımcı olur, çekirdek kaynak ağacındaki komut dosyası komut dosyaları / checkpatch.pl geliştirilmiştir. Bu komut dosyası sorunları kolayca gösterebilir ve bir geliştiricinin sorunları daha sonra işaret ederek zamanını boşa harcamak yerine, her zaman değişikliklerinde çalıştırılmalıdır.

Sanallaştırma, QEMU, VirtualBox veya Xen gibi bir şey yapmak için sanallaştırma kullandıklarını ve yapılandırmalar ve otomatik testler yapmak için bazı komut dosyaları kullandıklarını düşünürüm.

Otomatik test, muhtemelen çok sayıda rastgele yapılandırmayı veya birkaç belirli yapılandırmayı deneyerek yapılır (belirli bir sorunla çalışıyorlarsa). Linux, çekirdekten hata ayıklama verilerini izlemek ve günlüğe kaydetmek için birçok düşük düzey araçlara (dmesg gibi) sahiptir, bu yüzden bunun da kullanıldığını hayal ediyorum.

Ayrıca:

Sonuçları analiz etmek için karşılaştırmalı değerlendirme ve komut dosyası koleksiyonu olan MMTest'ler

https://github.com/gormanm/mmtests

Linux sistem çağrısı fuzz tester olan Trinity

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

Ayrıca sourceforge'daki LTP sayfaları oldukça eski ve proje GitHub'a taşındı https://github.com/linux-test-project/ltp

Bildiğim kadarıyla, Intel tarafından çalışan / fon sağlayan otomatik bir performans regresyon kontrol aracı (lkp / 0 gün) var, posta listesine gönderilen her geçerli yamayı test edecek ve hackbench gibi farklı mikrobençelerden değiştirilen puanları kontrol edecek , fio, unixbench, netperf, vb. bir performans regresyonu / iyileştirmesi olduğunda, ilgili bir rapor doğrudan yama yazarına ve Cc ile ilgili destekçilere gönderilecektir.

LTP ve Memtest'ler genellikle tercih edilen araçlardır.

adobriyan, Ingo'nun rasgele yapılandırma oluşturma testinden bahsetti. Bu hemen hemen 0 günlük test botu (aka kbuild test botu) tarafından kapsanmaktadır. Altyapı hakkında güzel bir makale burada sunulmaktadır: Çekirdek Oluşturma / önyükleme testi

Bu kurulumun arkasındaki fikir, geliştiricileri ASAP'a bildirerek hataları en kısa sürede düzeltebilmelerini sağlamaktır. (yamalar bazı durumlarda Linus ağacına girmeden önce, kbuild altyapısı aynı zamanda bakımcının alt sistem ağaçlarına karşı da test eder)

Linux çekirdeği derlemesi yapmıştım ve linux sürüm 3'ü kullandığım android (Marshmallow ve Nougat) için bazı Değişiklikler yaptım. Döngü deliğine giriyordu ya da girmiyordu. Mükemmel çalışırsa, sistem gereksinimlerine göre mükemmel bir şekilde derlendiği anlamına gelir.
MotoG çekirdek Derleme için

NOT: - Linux Çekirdeği, Sistem Donanımına bağlı gereksinimlere göre değişecektir

Katkıda bulunanlar yama dosyalarını gönderdikten sonra ve birleştirme isteği yaptıktan sonra linux gatekeepers, yamayı entegre ederek ve gözden geçirerek kontrol eder.Yarışarsa, yamayı ilgili dalda birleştirecek ve yeni sürüm sürümü yapacaklardır. Linux Test Projesi ( https://github.com/linux-test-project/ltp ), yamaları uyguladıktan sonra çekirdeklere karşı test senaryolarının (Test Durumları) çalıştırılmasını sağlayan ana kaynaktır. Bu yaklaşık 2 ~ 4 saat sürebilir ve bağlıdır. Seçili çekirdeğin dosya sistemi ile ilgili test yapılacağını lütfen unutmayın. Örn: Ext4, EXT3 vb.'ye karşı farklı sonuçlar üretir.

Çekirdek Test prosedürü.

1. Depodan en son çekirdek kaynağını alın. ( Https://www.kernel.org/Depodan veya Github.com)
2. Düzeltme eki dosyasını uygulama (Fark aracını kullanma)
3. Yeni çekirdek oluşturun.
4. LTP'deki test prosedürlerine karşı test edin ( https://github.com/linux-test-project/ltp )