Bagaimana cara membandingkan kernel Linux dengan arsitektur microkernel?


39

Saya pernah membaca bahwa salah satu keunggulan arsitektur microkernel adalah Anda dapat menghentikan / memulai layanan penting seperti jaringan dan sistem file, tanpa perlu me-restart seluruh sistem. Tetapi mengingat bahwa kernel Linux saat ini (apakah selalu demikian?) Menawarkan opsi untuk menggunakan modul untuk mencapai efek yang sama, apa kelebihan (tersisa) dari sebuah kernel mikro?



1
Anda dapat membaca debat tentang MicroKernel vs Monolithic kernel. oreilly.com/openbook/opensources/book/appa.html Dalam tulisan ini, Andrew Tanenbaum mendukung Microkernel dan Linus Torvalds mendukung kernel Monolithic.
Bhuwan 4-15

Jawaban:


35

Microkernels membutuhkan lebih sedikit kode untuk dijalankan dalam mode terdalam, paling tepercaya daripada kernel monolitik . Ini memiliki banyak aspek, seperti:

  • Microkernels memungkinkan fitur-fitur non-fundamental (seperti driver untuk perangkat keras yang tidak terhubung atau tidak digunakan) untuk dimuat dan dibongkar sesuka hati. Ini sebagian besar dapat dicapai di Linux, melalui modul.
  • Microkernels lebih tangguh: jika komponen non-kernel crash, ia tidak akan membawa keseluruhan sistem. Sistem file kereta atau driver perangkat dapat menyebabkan crash sistem Linux. Linux tidak memiliki cara untuk mengurangi masalah ini selain dari praktik pengkodean dan pengujian.
  • Microkernels memiliki basis komputasi tepercaya yang lebih kecil . Jadi bahkan driver perangkat berbahaya atau sistem file tidak dapat mengendalikan seluruh sistem (misalnya driver yang meragukan asal untuk gadget USB terbaru Anda tidak akan dapat membaca hard disk Anda).
  • Konsekuensi dari poin sebelumnya adalah bahwa pengguna biasa dapat memuat komponen mereka sendiri yang akan menjadi komponen kernel dalam kernel monolitik.

GUI Unix disediakan melalui jendela X, yang merupakan kode userland (kecuali untuk (bagian dari) driver perangkat video). Banyak kesatuan modern memungkinkan pengguna biasa memuat driver sistem file melalui FUSE . Beberapa penyaringan paket jaringan Linux dapat dilakukan di userland. Namun, driver perangkat, penjadwal, manajer memori, dan sebagian besar protokol jaringan masih hanya kernel.

Sebuah bacaan klasik (jika bertanggal) tentang Linux dan microkernels adalah debat Tanenbaum-Torvalds . Dua puluh tahun kemudian, dapat dikatakan bahwa Linux bergerak sangat lambat menuju struktur mikrokernel (modul yang dapat dimuat muncul lebih awal, FUSE lebih baru), tetapi masih ada jalan panjang yang harus ditempuh.

Hal lain yang telah berubah adalah meningkatnya relevansi virtualisasi pada desktop dan komputer tertanam kelas atas: untuk beberapa tujuan, perbedaan yang relevan bukan antara kernel dan userland tetapi antara hypervisor dan OS tamu.



1
Itu semua teori yang sangat bagus. Jika suatu perangkat terjepit entah bagaimana, sistem bersulang. Jika driver lumpuh setengah operasi, tidak ada restart driver akan mengembalikan sistem ke status fungsional. Jika Anda menginginkan kinerja apa pun, driver harus multithreaded ... dan keuntungan dari "satu penjadwal" benar-benar hilang. Ingin kinerja, Anda harus menghindari (semakin mahal) salinan memori dan sakelar konteks ... dan "modularitas" hilang. Cari ukuran beberapa microkernels, dan Anda akan melihat mereka ukuran dan kompleksitas yang sebanding dengan kernel monolitik dengan driver yang disertakan .
vonbrand

15

Sebuah microkernel membatasi waktu sistem dalam mode kernel, tidak seperti userspace, seminimal mungkin.

Jika crash terjadi dalam mode kernel, seluruh kernel turun, dan itu berarti seluruh sistem turun. Jika terjadi kerusakan dalam mode pengguna, proses itu hanya turun. Linux kuat dalam hal ini, tetapi masih memungkinkan bagi setiap subsistem kernel untuk menulis di atas memori subsistem kernel lainnya, baik secara sengaja atau tidak sengaja.

Konsep microkernel menempatkan banyak hal yang secara tradisional mode kernel, seperti jaringan dan driver perangkat, di userspace. Karena microkernel tidak terlalu bertanggung jawab atas banyak hal, itu juga berarti microkernel lebih sederhana dan lebih dapat diandalkan. Pikirkan cara protokol IP, dengan menjadi sederhana dan bodoh, benar-benar mengarah ke jaringan yang kuat dengan mendorong kerumitan ke tepi dan meninggalkan inti yang ramping dan jahat.


5

Terima kasih telah mengirim tautan ke bahan bacaan! Poin Brent W dalam abstrak adalah suara, dan sampai taraf tertentu, saya berempati dengan kepedulian Christoph L tentang kompleksitas yang berlebihan dalam mekanisme sinkronisasi kernel mikro; Namun, saya pikir makalah yang terakhir mungkin mengabaikan loop peristiwa berbasis pesan. Karena loop peristiwa tidak berbagi memori satu sama lain, kunci tidak diperlukan, dan karena (IMO) mereka meminjamkan diri ke gaya pengkodean deklaratif, algoritma yang konsisten dapat didefinisikan secara eksplisit (titik kalkulus lambda ...) - Saya biasanya memberi kode aplikasi, tetapi Q ini telah menjadi pengalaman belajar yang menyenangkan
Android antropik

1

Lihatlah arsitektur x86 - kernel monolitik hanya menggunakan cincin 0 dan 3. Sungguh sia-sia. Namun, sekali lagi ini bisa lebih cepat, karena lebih sedikit pengalihan konteks.

x86 berdering


Struktur cincin x86 hanya overengineering. Tidak ada penggunaan praktis (kecuali mesin virtual, tetapi yang semakin sering digunakan ...)
vonbrand

1
  1. Kernel monolitik jauh lebih tua dari kernel mikro . Ini digunakan di Unix sementara ide microkernel muncul pada akhir 1980 - an .

  2. Contoh OS yang memiliki kernel monolitik adalah UNIX, LINUX sedangkan OS yang memiliki microkernel adalah QNX, L4, HURD dan awalnya Mach (bukan MacOS X) yang kemudian dikonversi menjadi kernel hybrid. Bahkan MINIX bukanlah microkernel murni karena driver perangkatnya dikompilasi sebagai bagian dari kernel.

  3. Kernel monolitik lebih cepat dari kernel mikro . Microkernel Mach pertama adalah 50% lebih lambat dari kernel monolitik. Versi yang lebih baru seperti L4 hanya 2% atau 4% lebih lambat dari kernel monolitik .

  4. Kernel monolitik umumnya berukuran besar sementara microkernel murni harus berukuran kecil , bahkan masuk ke cache level pertama prosesor (microkernel generasi pertama).

  5. Dalam kernel monolitik, driver perangkat berada di ruang kernel sementara di driver perangkat microkernel berada di ruang pengguna .

  6. Karena driver perangkat berada di ruang kernel, itu membuat kernel monolitik kurang aman daripada microkernel (Kegagalan dalam driver dapat menyebabkan crash). Microkernels lebih aman daripada kernel monolitik, karenanya mereka digunakan di banyak perangkat militer.

  7. Kernel monolitik menggunakan sinyal dan soket untuk memastikan IPC sementara pendekatan microkernel menggunakan antrian pesan . 1 st gen dari microkernel buruk dilaksanakan IPC sehingga mereka lambat pada konteks switch.

  8. Menambahkan fitur baru ke sistem monolitik berarti mengkompilasi ulang seluruh kernel sementara Anda dapat menambahkan fitur atau tambalan baru tanpa mengkompilasi ulang


Dalam (4), Anda membandingkan apel dan semangka. Kernel mikro itu sendiri (dengan desain) hanya berisi fungsionalitas minimal, kernel monolitik mengandung lebih banyak. (6) adalah teori yang bagus, itu tergantung pada bagaimana kompeten potongan dikembangkan, dan bagaimana bocor yang nyata mekanisme IPC adalah (untuk kinerja, itu tidak bisa menjadi nyata "pesan lewat"). Catatan (7) berarti penanganan "antrian pesan" yang sangat kompleks, sehingga sebagian besar meniadakan kelebihannya. Untuk (8), dalam hal Linux misalnya, dimungkinkan untuk mengkompilasi modul yang tidak tergantung pada kernel. Ini secara rutin dilakukan untuk pengembangan driver.
vonbrand

0

Windows NT (kernel yang mendasari sistem Windows saat ini) dimulai sebagai desain microkernel yang cukup vanilla. Karena masalah kinerja, semakin banyak kode "userland" bermigrasi ke "mikokernel" ... hari ini struktur mikrokernelnya masih asli.


-1

Kasusnya adalah bahwa kernel linux adalah hybrid dari monolithic dan microkernel. Dalam implementasi monolitik murni tidak ada modul yang memuat saat runtime.


9
ini bukan. fakta bahwa modul dimuat secara dinamis tidak mengubah fakta, bahwa mereka dijalankan dengan hak istimewa kernel penuh, dan sebagai bagian dari kernel monolitik.
vartec

3
Untuk desain hybrid, akan lebih penting ketika beberapa driver (untuk USB, Scanner, Printer dan grafik) diimplementasikan di userspace daripada kernel. Perbedaannya tidak jelas dan Linux dapat dinyatakan sebagai kernel hybrid karena ada libusb, waras, gelas dan mesa - bukan karena ada insmod dan rmmod.
Maciej Piechotka

-1

Syarat-syarat monolithic kerneldan microkerneltidak dapat secara serius dibandingkan karena mereka menggambarkan berbagai aspek dari desain kernel (struktur vs ukuran).

Kernel monolitik khas adalah kernel SunOS-4.x dan Linux masih serupa, karena Anda secara manual mengkonfigurasi konten kernel dasar.

Kernel Solaris (dimulai dengan 2.1 pada 1992) tidak dapat disebut monolitik lagi karena semua driver dimuat secara otomatis sesuai permintaan dan hanya sebagian kecil yang dimuat saat boot awal.

SunOS-4.x dan Solaris (SunOS-5.x) dan Linux adalah implementasi konteks tunggal. Seluruh kode mereka berjalan dalam konteks MMU tunggal.

Mac OS X didasarkan pada Mach dan berjalan sebagai implementasi multi konteks dengan beberapa proses yang dipisahkan oleh konteks MMU. Dalam konsep ini, driver berada dalam proses yang terpisah dan konteks MMU yang terpisah.

Banyak orang menyebut Mac OS X sebagai "sistem mikrokernel", tetapi mungkin bahwa kernel dasar tidak lebih kecil dari kernel dasar dari Solaris.

Jadi sepertinya bahwa akan lebih baik untuk bicara tentang single context kernelsvs multi context kernels.


1
MacOS menjalankan shim BSD (dasarnya monolitik) di atas microkernel. Tidak ada pemisahan menjadi proses terpisah sama sekali di sana, bukan desain microkernel nyata .
vonbrand

1
Jadi Anda mengakui desain yang menggunakan setidaknya dua proses kernel. Istilah microkernelitu salah pula karena biasanya digunakan untuk sesuatu yang harus dipanggil multi context kernel.
schily
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.