Mengapa API modul Linux tidak kompatibel dengan versi sebelumnya?
Mengapa API modul Linux tidak kompatibel dengan versi sebelumnya? Saya frustrasi menemukan driver yang diperbarui setelah memperbarui kernel Linux.
Saya memiliki adaptor nirkabel yang membutuhkan driver berpemilik, tetapi pabrikan telah menghentikan perangkat ini sekitar 7 tahun yang lalu. Karena kodenya sangat tua dan ditulis untuk Linux 2.6.0.0, ia tidak dapat dikompilasi dengan kernel Linux terbaru. Saya telah menggunakan banyak distribusi Linux tetapi masalah yang sama ada di mana-mana. Meskipun ada driver open-source yang didistribusikan dengan kernel Linux, itu tidak berfungsi. Beberapa orang mencoba memodifikasi kode kepemilikan lama agar kompatibel dengan kernel Linux terbaru, tetapi ketika kernel Linux baru dirilis, dibutuhkan waktu berbulan-bulan untuk membuat kode kompatibel dengan itu. Dalam waktu itu, versi baru lainnya dirilis. Karena alasan ini, saya tidak dapat mengupgrade ke kernel Linux baru; terkadang saya bahkan tidak dapat meningkatkan distribusi saya.
Jawaban
Greg Kroah-Hartman telah menulis tentang topik ini di sini: https://www.kernel.org/doc/html/v4.10/process/stable-api-nonsense.html
Selain beberapa detail teknis tentang kompilasi kode C, dia menarik beberapa masalah rekayasa perangkat lunak dasar yang membuat keputusan mereka.
Kernel Linux selalu dalam proses. Ini terjadi karena berbagai alasan:
- Persyaratan baru muncul. Orang-orang ingin perangkat lunak mereka berbuat lebih banyak, itulah sebabnya kebanyakan dari kita meningkatkan, kita menginginkan fitur terbaru dan terhebat. Ini mungkin memerlukan pengerjaan ulang ke perangkat lunak yang ada.
- Bug ditemukan yang perlu diperbaiki, terkadang bug ada dengan desain itu sendiri dan tidak dapat diperbaiki tanpa pengerjaan ulang yang signifikan
- Ide dan idiom baru dalam dunia perangkat lunak terjadi dan orang menemukan cara yang lebih mudah / elegan / efisien untuk melakukan sesuatu.
Hal ini berlaku untuk sebagian besar perangkat lunak , dan perangkat lunak apa pun yang tidak dipelihara akan mati secara perlahan dan menyakitkan . Apa yang Anda tanyakan adalah mengapa kode lama yang tidak terawat itu masih berfungsi?
Mengapa antarmuka lama tidak dipertahankan?
Untuk memastikan kompatibilitas ke belakang, antarmuka lama (sering "rusak" dan tidak aman) harus dipertahankan. Tentu saja secara teoritis mungkin untuk melakukan ini kecuali itu membawa biaya yang signifikan .
Greg Kroah-Hartman menulis
Jika Linux harus memastikan bahwa ia akan mempertahankan antarmuka sumber yang stabil, antarmuka baru akan dibuat, dan antarmuka yang lebih lama dan rusak harus dipertahankan dari waktu ke waktu, yang mengarah ke pekerjaan ekstra untuk [pengembang]. Karena semua [pengembang] Linux melakukan pekerjaan mereka pada waktu mereka sendiri, meminta programmer untuk melakukan pekerjaan ekstra tanpa keuntungan, gratis, bukanlah suatu kemungkinan.
Meskipun Linux bersifat open source, waktu pengembang untuk mempertahankannya masih terbatas. Jadi tenaga kerja masih bisa dibicarakan dalam istilah "biaya". Pengembang harus memilih cara mereka menghabiskan waktu:
- Menghabiskan banyak waktu untuk memelihara antarmuka lama / rusak / lambat / tidak aman. Ini terkadang bisa dua kali lipat menjadi tiga kali lipat waktu yang dibutuhkan untuk menulis antarmuka dalam contoh pertama.
- Buang antarmuka lama dan harapkan pengelola perangkat lunak lain [melakukan tugas mereka dan] memelihara perangkat lunak mereka sendiri.
Pada keseimbangan, antarmuka binning benar-benar hemat biaya (untuk pengembang kernel) . Jika Anda ingin tahu mengapa pengembang tidak menghabiskan berbulan-bulan dan bertahun-tahun hidup mereka menyelamatkan Anda dari membayar $ 10 untuk adaptor wifi baru ... itulah alasannya. Ingatlah bahwa waktu / biaya efektif untuk pengembang kernel, belum tentu hemat biaya untuk Anda atau produsen.
Meskipun saya telah menyumbangkan beberapa tambalan (sangat kecil) ke kernel Linux, saya tidak menganggap diri saya sebagai pengembang kernel. Namun, inilah yang saya ketahui:
Sebuah driver yang ditulis untuk kernel versi 2.6.0.0 sebelum penghapusan Big Kernel Lock (BKL) yang terjadi di versi kernel 2.6.39.
BKL dibuat kembali ketika Linux masih OS dengan prosesor tunggal (single-core, single-thread). Segera setelah dukungan SMP ditambahkan, para pengembang menyadari bahwa BKL akan menjadi hambatan besar di beberapa titik, tetapi selama hanya ada beberapa inti / utas dalam sistem secara total, itu agak lumayan. Tapi pertama kali menjadi masalah nyata bagi orang yang menggunakan Linux di superkomputer, dan pekerjaan mulai menggantikan semua yang membutuhkan BKL dengan mekanisme penguncian yang lebih halus, atau bila memungkinkan, dengan metode tanpa kunci.
Pada komputer modern, yang mungkin memiliki dua digit jumlah inti pada desktop biasa dan laptop berdaya tinggi, apalagi server, API modul kernel yang kompatibel dengan 2.6.0 juga perlu mengimplementasikan BKL.
Jika modul lama mengatakan "Saya ingin mengambil BKL", kernel lainnya tidak tahu apa yang akan dilakukan modul tersebut dengannya, sehingga mekanisme kompatibilitas mundur harus mengambil semua kunci yang menggantikan BKL hanya untuk menutupi semua kemungkinan. Itu akan menjadi hit kinerja yang besar. Dan metode tanpa kunci yang baru juga perlu memeriksa kunci lama - yang pada awalnya mengalahkan poin tanpa kunci. Jadi, keberadaan mekanisme kompatibilitas mundur akan menurunkan kinerja sistem, bahkan jika tidak ada modul lama yang benar-benar dimuat.
Baru-baru ini, patch keamanan Spectre / Meltdown membuat perubahan besar tentang apa yang perlu terjadi saat batas kernel / userspace dilintasi. Setiap modul yang dikompilasi sebelum perbaikan Spectre / Meltdown diimplementasikan tidak dapat diandalkan dengan kernel pasca-Specre / Meltdown.
Hanya dua minggu yang lalu saya memecahkan masalah server lama yang membutuhkan perputaran daya manual ketika pembaruan keamanan diterapkan oleh otomatisasi. Ini telah terjadi beberapa kali sebelumnya, dan dapat direproduksi. Saya menemukan bahwa itu memiliki versi yang sangat lama dari megasrdriver penyimpanan berpemilik dari sebelum patch Spectre / Meltdown, yang tidak termasuk dalam pembaruan otomatis. Setelah memperbarui driver ke versi saat ini, masalahnya hilang. Omong-omong, ini menggunakan sistem RHEL 6.10 biasa.
Saya juga melihat server mogok saat memuat driver pemantauan perangkat keras pra-Spectre / Meltdown dengan kernel pasca-Spectre / Meltdown. Berdasarkan pengalaman ini, saya sepenuhnya yakin bahwa perbaikan Spectre / Meltdown perlu diperlakukan sebagai peristiwa penting: kernel dan modul harus berupa semua sebelum perbaikan, atau semua versi setelah perbaikan; mencampur dan mencocokkan hanya akan menyebabkan kesedihan dan panggilan bangun tengah malam untuk sysadmin panggilan.
Dan karena Specter adalah masalah tingkat desain CPU , itu adalah "hadiah yang terus memberi": beberapa orang akan menemukan cara baru untuk mengeksploitasi kelemahan, dan kemudian pengembang kernel perlu mencari cara untuk memblokir eksploitasi.
Ini hanyalah dua masalah besar yang perlu dipecahkan oleh API modul kernel lama yang kompatibel dengan 2.6.0.0. Saya yakin masih banyak lainnya.
Dan kemudian ada sisi yang lebih filosofis. Pikirkan tentang ini: apa yang memungkinkan Linux?
Sebagian besar darinya adalah spesifikasi perangkat keras terbuka . Jika spesifikasi perangkat keras terbuka, siapa pun dapat berpartisipasi. Karena kode sumber sistem operasi terbuka, siapa pun dapat berkontribusi, untuk kepentingan semua orang. Dan Anda tidak dapat menyimpan spesifikasi pemrograman perangkat keras sebagai rahasia dagang Anda jika kode driver Anda bersumber terbuka.
Pengembang kernel Linux cenderung percaya pada model open source. Itulah mengapa mereka telah membuat pilihan desain dan pengembangan mereka sehingga cara yang disukai bagi produsen perangkat keras untuk berpartisipasi adalah dengan open source driver, menggabungkannya ke dalam distribusi sumber kernel utama, dan kemudian (dan hanya kemudian ) Anda akan mendapatkan manfaat dari seluruh komunitas pengembang kernel dalam memeliharanya.
Hal ini memberikan insentif kepada perancang dan produsen perangkat keras untuk memungkinkan hal ini. Jika Anda memiliki sesuatu yang ingin dirahasiakan, lakukan upaya merangkumnya menjadi ASIC, atau mungkin ke dalam firmware yang ditandatangani jika perlu. (Jika Anda melakukan yang terakhir, berikan izin kepada orang lain untuk mendistribusikan ulang paket firmware.)
Tetapi karena kernel adalah open source, pengembang kernel tidak dapat secara tepat mencegah orang lain memelihara driver berpemilik secara terpisah. Tapi mereka juga tidak punya insentif untuk peduli pada mereka.
Faktanya, kerumitan ekstra yang disebabkan oleh driver biner berpemilik dalam debugging kernel adalah insentif bagi pengembang kernel untuk tidak peduli dengan pengembangan driver berpemilik: "Mereka membuat pekerjaan saya lebih sulit, mengapa saya harus melakukan sesuatu secara khusus untuk mempermudah pekerjaan mereka?"
Jadi, para pengembang kernel umumnya melakukan apa yang paling menguntungkan bagi mereka sebagai kelompok / komunitas. Jika itu termasuk beberapa perubahan API modul, biarlah. Pengemudi pihak ketiga bahkan tidak memasukkan persamaan.