Bagaimana kernel Linux diuji?


258

Bagaimana pengembang kernel Linux menguji kode mereka secara lokal dan setelah mereka berkomitmen? Apakah mereka menggunakan semacam unit test, automation build? rencana pengujian?


16
youtube.com/watch?v=L2SED6sewRw , di suatu tempat, saya tidak ingat persis, tapi saya pikir di bagian QA ini sedang dibicarakan.
Anders

6
Tautan Anders sangat bagus - Google Tech Talk oleh salah satu pengembang kernel teratas, Greg Kroah Hartman. Ia memvalidasi jawaban yang diberikan di bawah ini oleh pengembang kernel @adobriyan. Greg mencatat hal yang menyenangkan tentang kernel - tidak ada cara yang baik untuk menguji tanpa menjalankannya - sulit untuk melakukan tes unit dll - banyak permutasi. "Kami mengandalkan komunitas pengembangan untuk menguji. Kami ingin sebanyak mungkin tes fungsional, dan juga tes kinerja." Tautan langsung ke diskusi pengujian adalah youtube.com/...
nealmcb

Dengan popularitas VM, tidak mungkin untuk mengotomatisasi ini dengan membangun kernel dengan sekelompok permutasi konfigurasi dan mencoba untuk boot pada mereka? Itu tidak akan menjadi tes "unit" dengan cara apa pun, tapi itu bisa menangkap bug.
Daniel Kaplan

@DanielKaplan: Jika Anda berasumsi ada sekitar 1.000 motherboard yang masing-masing memiliki satu dari 10 CPU, ditambah 3 dari 1000 perangkat PCI, ditambah 3 dari 1000 perangkat USB; dan bahwa kernel memiliki 1000 opsi waktu kompilasi yang berbeda; maka Anda melihat sekitar 1000 * 10 * 1000 * 999 * 9981000 * 999 * 998 * 1000 kemungkinan permutasi untuk diuji. Jika Anda melakukan pembakaran 8 jam yang bagus dalam pengujian untuk setiap permutasi dan memiliki kumpulan 100 server untuk menjalankan 400 VM secara paralel pada saat yang sama; maka pada saat Anda sudah mendapat 1 juta dari itu diuji hasilnya semua akan usang karena seseorang mengubah kode dan Anda harus mulai lagi.
Brendan

Ada sedikit diskusi tentang unit test pada ycombinator.
joeytwiddle

Jawaban:


76

Kernel linux memiliki penekanan besar pada pengujian komunitas.

Biasanya setiap pengembang akan menguji kode mereka sendiri sebelum mengirimkan, dan cukup sering mereka akan menggunakan versi pengembangan dari kernel dari Linus, atau salah satu pohon pengembangan / tidak stabil lainnya untuk proyek yang relevan dengan pekerjaan mereka. Ini berarti mereka sering menguji baik perubahan mereka maupun perubahan orang lain.

Biasanya tidak ada banyak rencana pengujian formal, tetapi pengujian tambahan mungkin diminta sebelum fitur digabungkan ke dalam pohon hulu.

Seperti yang ditunjukkan oleh Dean, ada juga beberapa pengujian otomatis, proyek pengujian linux dan kernel autotest ( gambaran bagus ).

Pengembang akan sering juga menulis tes otomatis yang ditargetkan untuk menguji perubahan mereka, tetapi saya tidak yakin ada mekanisme (yang sering digunakan) untuk secara terpusat mengumpulkan tes adhoc ini.

Itu sangat tergantung pada area kernel mana yang sedang diubah tentunya - pengujian yang akan Anda lakukan untuk driver jaringan baru sangat berbeda dengan pengujian yang akan Anda lakukan ketika mengganti algoritma penjadwalan inti.


8
+1, setengah dari pertempuran tidak hanya menghancurkan sesuatu yang bergantung pada driver, karenanya kegigihan BKL selama bertahun-tahun. Hal lain yang perlu dipertimbangkan adalah menguji banyak sub sistem pada banyak arsitektur yang berbeda, yang secara praktis hanya layak dengan jenis penyalahgunaan komunitas, salah pengujian, yang diterima Linux.
Tim Post

66

Secara alami, kernel itu sendiri dan bagian-bagiannya diuji sebelum rilis, tetapi tes ini hanya mencakup fungsionalitas dasar. Ada beberapa sistem pengujian yang melakukan pengujian Linux Kernel:

Linux Test Project (LTP) memberikan suite pengujian kepada komunitas open source yang memvalidasi keandalan dan stabilitas Linux. Rangkaian uji LTP berisi kumpulan alat untuk menguji kernel Linux dan fitur terkait. https://github.com/linux-test-project/ltp

Autotest - kerangka kerja untuk pengujian sepenuhnya otomatis. Ini dirancang terutama untuk menguji kernel Linux, meskipun berguna untuk banyak tujuan lain seperti kualifikasi perangkat keras baru, pengujian virtualisasi, dan pengujian program ruang pengguna umum lainnya di bawah platform Linux. Ini adalah proyek open-source di bawah GPL dan digunakan dan dikembangkan oleh sejumlah organisasi, termasuk Google, IBM, Red Hat, dan banyak lainnya. http://autotest.github.io/

Juga ada sistem sertifikasi yang dikembangkan oleh beberapa perusahaan distribusi utama GNU / Linux. Sistem ini biasanya memeriksa distribusi GNU / Linux lengkap untuk kompatibilitas dengan perangkat keras. Ada sistem sertifikasi yang dikembangkan oleh Novell, Red Hat, Oracle, Canonical, Google .

Ada juga sistem untuk analisis dinamis dari kernel Linux:

Kmemleak adalah detektor kebocoran memori yang termasuk dalam kernel Linux. Ini menyediakan cara untuk mendeteksi kemungkinan kebocoran memori kernel dengan cara yang mirip dengan melacak pengumpul sampah dengan perbedaan bahwa objek yatim tidak dibebaskan tetapi hanya dilaporkan melalui / sys / kernel / debug / kmemleak.

Kmemcheck memerangkap setiap membaca dan menulis ke memori yang dialokasikan secara dinamis (yaitu dengan kmalloc ()). Jika alamat memori sudah dibaca yang belum pernah ditulis sebelumnya, sebuah pesan dicetak ke log kernel. Juga merupakan bagian dari Kernel Linux

Kerangka Injeksi Kesalahan (termasuk dalam kernel Linux) memungkinkan untuk memasukkan kesalahan dan pengecualian ke dalam logika aplikasi untuk mencapai cakupan yang lebih tinggi dan toleransi kesalahan sistem.


62

Bagaimana pengembang kernel Linux menguji kode mereka secara lokal dan setelah mereka berkomitmen?

Apakah mereka menggunakan semacam unit test, automation build?

Dalam arti kata klasik, tidak.

E. g. Ingo Molnar menjalankan beban kerja berikut: 1. membangun kernel baru dengan opsi konfigurasi set acak 2. boot ke dalamnya 3. goto 1

Setiap build gagal, boot gagal, BUG atau peringatan runtime ditangani. 24/7. Kalikan dengan beberapa kotak, dan satu dapat mengungkap cukup banyak masalah.

rencana pengujian?

Tidak.

Mungkin ada kesalahpahaman bahwa ada fasilitas pengujian pusat, tidak ada. Setiap orang melakukan apa yang diinginkannya.


6
Mengingat keberadaan situs seperti ini dan ini saya juga akan mempertanyakan validitas jawaban ini.
Dean Harding

3
Saya pikir inti dari jawaban adobriyan "ada fasilitas pengujian pusat, tidak ada." sekitar benar. Namun kelompok yang berbeda melakukan berbagai tingkat pengujian, seolah-olah kernel tersebut sama sekali tidak diuji.
stsquad

2
Saya pikir baik SUSE dan RedHat selain menguji kernel mereka sendiri, uji vanilla sering. Tidak ada pengujian pusat per se, tetapi ada pengujian yang sedang berlangsung - oleh pengguna utama Linux. Kalau tidak, komentar tersebut berdiri. Seandainya itu ditulis dengan kurang sarkastik, saya bahkan akan mengubahnya.
Dummy00001

55
Errr, apakah Anda semua orang menyadari bahwa Alexey Dobriyan adalah pengembang kernel Linux?
ninjalj

9
Sebagai pengembang kernel lain, saya harus mengatakan ini adalah jawaban yang paling jujur ​​untuk pertanyaan: kernel TIDAK diuji dalam arti klasik, hanya karena itu tidak mungkin. Ada lebih banyak kombinasi konfigurasi dan perangkat keras daripada waktu pengembang yang tersedia untuk menguji. Sangat sedikit orang yang memiliki keterampilan yang diperlukan untuk menguji perangkat tertentu, dan dalam beberapa kasus sangat sedikit orang yang benar-benar memiliki perangkat tertentu.
Ezequiel Garcia

19

Alat di dalam pohon

Cara yang baik untuk menemukan alat uji di kernel adalah dengan:

Di v4.0, ini mengarahkan saya ke:

Kernel CI

https://kernelci.org/ adalah proyek yang bertujuan untuk membuat pengujian kernel lebih otomatis dan terlihat.

Tampaknya hanya melakukan pengujian build dan boot (TODO cara menguji secara otomatis bahwa boot source bekerja harus di https://github.com/kernelci/ ).

Linaro tampaknya menjadi pengelola utama proyek ini, dengan kontribusi dari banyak perusahaan besar: https://kernelci.org/sponsors/

Linaro Lava

http://www.linaro.org/initiatives/lava/ terlihat seperti sistem CI dengan fokus pada pengembangan papan pengembangan dan kernel Linux.

LISA LENGAN

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

Tidak yakin apa yang dikerjakannya secara detail, tetapi oleh ARM dan Apache Licensed, jadi sepertinya layak untuk dilihat.

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

Langkah debuggers

Tidak benar-benar unit testing, tetapi dapat membantu setelah tes Anda mulai gagal:

Pengaturan QEMU + Buildroot + Python saya sendiri

Saya juga memulai pengaturan yang berfokus pada kemudahan pengembangan, tetapi akhirnya saya menambahkan beberapa kemampuan pengujian sederhana juga: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508782827320209644dcbaf9a6b3141724#test-this -laporan

Saya belum menganalisis semua pengaturan lain dengan sangat terperinci, dan mereka kemungkinan melakukan lebih dari yang saya miliki, namun saya percaya bahwa pengaturan saya sangat mudah untuk memulai dengan cepat karena memiliki banyak dokumentasi dan otomatisasi.


13

Tidak sangat mudah untuk mengotomatisasi pengujian kernel. Sebagian besar pengembang Linux melakukan pengujian sendiri, seperti yang disebutkan adobriyan.

Namun, ada beberapa hal yang membantu men-debug Kernel Linux:

  • kexec: Panggilan sistem yang memungkinkan Anda untuk memasukkan kernel lain ke dalam memori dan reboot tanpa kembali ke BIOS, dan jika gagal, reboot kembali.
  • dmesg: Pasti tempat untuk mencari informasi tentang apa yang terjadi selama boot kernel dan apakah itu berfungsi / tidak berfungsi.
  • Instrumentasi Kernel: Selain printk (dan opsi yang disebut 'CONFIG_PRINTK_TIME' yang memungkinkan Anda melihat (ke akurasi mikrodetik) ketika kernel menghasilkan apa), konfigurasi kernel memungkinkan Anda untuk menghidupkan BANYAK pelacak yang memungkinkan mereka untuk men-debug apa sedang terjadi.

Kemudian, pengembang biasanya meminta orang lain meninjau tambalan mereka. Setelah tambalan ditinjau secara lokal dan terlihat tidak mengganggu hal lain, dan tambalan diuji untuk bekerja dengan kernel terbaru dari Linus tanpa merusak apa pun, tambalan didorong ke hulu.

Sunting: Berikut adalah video yang bagus yang merinci proses yang dilalui patch sebelum diintegrasikan ke dalam kernel.


6

Selain poin di atas / di bawah ini, yang lebih menekankan pada pengujian fungsionalitas, pengujian sertifikasi perangkat keras, dan pengujian kinerja kernel Linux.

Banyak pengujian yang sebenarnya terjadi, sebenarnya skrip, alat analisis kode statis, ulasan kode, dll. Yang sangat efisien dalam menangkap bug, yang jika tidak akan merusak sesuatu dalam aplikasi.

Jarang - Alat sumber terbuka yang dirancang untuk menemukan kesalahan pada kernel Linux.

Coccinelle adalah program lain yang melakukan pencocokan dan transformasi mesin yang menyediakan bahasa SmPL (Semantic Patch Language) untuk menentukan kecocokan yang diinginkan dan transformasi dalam kode C.

checkpatch.pl dan skrip lainnya - masalah gaya pengkodean dapat ditemukan dalam file Documentation / CodingStyle di pohon sumber kernel. Yang penting untuk diingat ketika membacanya bukanlah bahwa gaya ini entah bagaimana lebih baik daripada gaya lainnya, hanya saja itu konsisten. ini membantu pengembang dengan mudah menemukan dan memperbaiki masalah gaya pengkodean, skrip script / checkpatch.pl di pohon sumber kernel telah dikembangkan. Skrip ini dapat menunjukkan masalah dengan mudah, dan harus selalu dijalankan oleh pengembang pada perubahannya, alih-alih meminta pengulas membuang waktu dengan menunjukkan masalah di kemudian hari.


3

Saya akan membayangkan mereka menggunakan virtualisasi untuk melakukan tes cepat, sesuatu seperti QEMU, VirtualBox atau Xen, dan beberapa skrip untuk melakukan konfigurasi dan tes otomatis.

Pengujian otomatis mungkin dilakukan dengan mencoba banyak konfigurasi acak atau beberapa yang spesifik (jika mereka bekerja dengan masalah tertentu). Linux memiliki banyak alat level rendah (seperti dmesg) untuk memonitor dan mencatat data debug dari kernel, jadi saya membayangkan itu digunakan juga.


Anda pasti benar. Ketika saya melakukan pengembangan modul kernel, saya sangat bergantung pada VirtualBox + KGDB untuk LINE-BY-LINE melacak eksekusi kernel. Ya, gdb untuk melihat seluruh kernel mengeksekusi baris demi baris benar-benar keren. Sama dengan Valerie Aurora, pengembang kernel terkenal, misalnya: youtube.com/watch?v=Tach2CheAc8 . Di dalam video Anda dapat melihat bagaimana dia menggunakan virtualisasi UserModeLinux untuk melangkah melalui kernel.
Peter Teoh


1

Sejauh yang saya tahu, ada alat pemeriksaan regresi kinerja otomatis (bernama lkp / 0 hari) dijalankan / didanai oleh Intel, itu akan menguji setiap tambalan yang valid yang dikirim ke milis dan memeriksa skor yang diubah dari berbagai microbenchmark seperti hackbench , fio, unixbench, netperf, dll, begitu ada regresi / peningkatan kinerja, laporan terkait akan dikirim langsung ke pembuat tambalan dan pengelola terkait Cc.



0

adobriyan menyebut pengulangan pengujian konfigurasi confo buatan Ingo. Sekarang sudah cukup banyak yang dicakup oleh bot uji 0-hari (alias bot uji kbuild). Artikel bagus tentang infrastruktur disajikan di sini: Kernel Build / boot testing

Gagasan di balik pengaturan ini adalah untuk memberi tahu pengembang ASAP sehingga mereka dapat memperbaiki kesalahan segera. (sebelum tambalan membuatnya menjadi pohon Linus dalam beberapa kasus karena infrastruktur kbuild juga menguji terhadap pohon subsistem pemelihara)


0

Saya telah melakukan kompilasi kernel linux dan melakukan beberapa modifikasi untuk android (Marshmallow dan Nougat) di mana saya menggunakan linux versi 3. Saya mengkompilasinya secara silang dalam sistem linux, men-debug kesalahan secara manual dan kemudian menjalankan file boot image-nya di Android dan memeriksa apakah itu akan di loop-hole atau tidak. Jika berjalan sempurna maka itu berarti dikompilasi dengan sempurna sesuai dengan persyaratan sistem.
Untuk Kompilasi kernel MotoG

CATATAN: - Kernel Linux akan berubah sesuai dengan persyaratan yang bergantung pada Perangkat Keras Sistem


0

Sekali setelah kontributor mengirimkan file tambalan mereka & setelah membuat permintaan gatekeeper linux memeriksa tambalan dengan mengintegrasikan & memeriksanya. Sekali jika berhasil mereka akan menggabungkan tambalan ke cabang yang relevan & membuat rilis versi baru. Proyek Uji Linux ( https://github.com/linux-test-project/ltp ) adalah sumber utama yang menyediakan skenario pengujian (Kasus Uji) untuk dijalankan terhadap kernel setelah menerapkan tambalan. Ini mungkin memakan waktu sekitar 2 ~ 4 jam & tergantung. Harap perhatikan tentang sistem file dari kernel yang Dipilih yang akan diuji. Contoh: Ext4 menghasilkan hasil yang berbeda dengan EXT3 & seterusnya.

Prosedur Pengujian Kernel.

  1. Dapatkan sumber kernel terbaru dari repositori. ( Https://www.kernel.org/ atau Github.com)
  2. Terapkan file tambalan (Menggunakan alat Diff)
  3. Bangun kernel baru.
  4. Uji terhadap prosedur pengujian dalam LTP ( https://github.com/linux-test-project/ltp )
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.