Bukankah Android kernel umum yang digunakan di semua perangkat? Misalnya CentOS akan diinstal pada Dell, HP, dan berbagai perangkat keras lainnya. Tentu ada modul yang berbeda tapi tetap saja CentOS.
Apa alasan mengapa CyanogenMod selalu "rusak"? Saya selalu mendengar di forum mereka sedang mengerjakan porting driver ini atau driver itu. Jika mereka menggunakan kernel yang sama, bukankah drivernya akan berfungsi dengan baik? Saya juga melihat jutaan jenis kernel untuk perangkat yang berbeda.
Jawaban:
Kernel bervariasi dari produsen ke produsen. Banyak dari kernel tersebut berasal dari sumber kernel murni yang ditemukan di CAF, yang dilakukan oleh produsen ini adalah mengambil sumber stok tersebut, memodifikasinya sesuai dengan papan / chipset yang digunakan, juga, mengimplementasikan driver mereka sendiri.
Perhatikan baik-baik di sekitar Anda, ada variasi layar sentuh, variasi chipset wifi, belum lagi, akselerometer, sensor, baterai, kompas, suara, grafik.
Mengambil satu sumber kernel dari HTC misalnya tidak akan berfungsi pada Samsung, dan sebaliknya.
Pabrikan bebas untuk memilih-ceri atau mengambil-out berbagai bit yang bisa dimasukkan ke dalam papan sirkuit. Tidak ada aturan keras atau cepat yang terlibat. Karenanya banyak peretasan / modifikasi agar kernel berfungsi dengan baik.
Anda tidak boleh, dibandingkan dengan kernel distribusi Linux desktop yang memiliki PCI, PCI-Express, SATA, VGA, SVGA, USB, Ethernet karena mereka adalah permainan ball-park yang sama sekali berbeda. Perbedaan utama dengan CentOS dan dengan Kernel Linux Android adalah ini - SEMUA driver dikompilasi baik sebagai modul atau built-in, maka setiap distribusi Linux hanya akan "bekerja di luar kotak". Sekali lagi, dengan distribusi Linux desktop - Anda memiliki satu arsitektur - x86 karenanya satu kernel Linux dari katakanlah Dell PC, dapat bekerja di luar kotak pada Lenovo asalkan driver standar rawa dikompilasi.
Jangan lupa, di dunia Android, ada variasi dari kernel yang dibangun untuk chipset ARM tertentu, seperti ARMv6, ARMv7, ada TEGRA, ada EXYNOS, dan mereka biner tidak kompatibel satu sama lain. Karenanya jika kernel dikompilasi untuk TEGRA, lupakan saja, itu tidak akan berfungsi pada ARMv7!
Alasan beberapa kernel di Android tampaknya "rusak" adalah ke pembuatnya. Beberapa (Zte adalah salah satu contoh yang sangat baik) melepaskan sumber yang dibantai yang dapat dikompilasi dari sumber tetapi gagal untuk boot karena driver yang hilang yang tidak tercakup oleh lisensi GPLv2 atau GPLv3. Itulah masalahnya, oleh karena itu beberapa peretas harus pergi berkeliling github mencari beberapa petunjuk; beberapa produsen, jika tidak semua, patuh. Inkarnasi sumber Zte saat ini konon adalah 2.6.35.7, tetapi dalam kenyataannya basis sumber 2.6.32.9 sebenarnya dengan banyak modifikasi sehingga tidak mewakili sumber kernel sejati untuk 2.6.35.7!
Di sinilah produsen harus merilis sumbernya masing-masing, tidak hanya karena tidak sesuai dengan GPLv2 atau yang lebih baru, tetapi lebih bagi komunitas untuk dapat memodifikasinya, seperti menambahkan kemampuan overclocking.
Oleh karena itu ada peretasan yang terlibat di balik layar dan banyak mengotak-atik driver yang mencoba membuatnya berfungsi, dan tidak mudah untuk debug juga .. Beberapa driver mungkin memiliki lisensi silang, TETAPI tidak dapat didistribusikan tergantung pada klausa dan ketentuannya seperti dinegosiasikan.
Untungnya, itu semua berubah sekarang dengan sumber kernel 3.xx, karena driver Android sekarang terintegrasi ke sumber-sumber utama. Tapi ada gotcha!
Coba porting kernel 3.xx ke handset yang sudah ada yang berumur sekitar 12-18 bulan; Bukan peluang bola salju di neraka akan berhasil, itu karena, dari faktor yang berbeda, sumber 3.xx sangat berbeda dengan sumber 2.6.x dan akan mengambil banyak peretasan untuk membuatnya berfungsi - saya harus tahu, telah mencoba porting sumber 2.6.38.6 untuk Zte Blade dan gagal.
Demikian juga, rilis kernel 3.0.1 terbaru - ketika mengerjakan proyek ics4blade di Modaco, telah melakukan banyak upaya untuk port itu tetapi itu ke fakta sederhana bahwa Zte membuat kekacauan yang sangat buruk dari sumber yang membuat porting hampir tidak mungkin dilakukan .
Arsitektur PC dibangun di sekitar bagian-bagian komoditas karena ia dimulai sebagai klon dari produk tertentu, PC IBM, yang secara khusus dirancang agar kompatibel dengannya, dan karenanya satu sama lain. Secara umum, Anda dapat mengambil program atau perangkat periferal dari satu PC yang kompatibel dan memasukkannya ke yang lain, dan mengharapkannya berfungsi. Kemampuan itu cukup berguna sehingga orang terus menuntutnya bahkan ketika teknologinya berkembang. Anda dapat meletakkan kartu PCI Express di PC modern apa pun seperti Anda dapat memasukkan kartu ISA di klon PC mana pun saat itu.
Smartphone tidak memiliki riwayat seperti itu. Mereka dirancang sebagai produk monolitik, sistem lengkap yang terdiri dari perangkat keras dan perangkat lunak yang "hanya berfungsi" apa adanya. Tidak ada harapan bahwa orang akan mengambil bagian dari satu telepon dan memasukkannya ke yang lain, sehingga para insinyur tidak perlu memperhitungkan interoperabilitas ketika mereka merancang produk mereka.
Bahkan di dalam pohon sumber kernel Linux, ada banyak fragmentasi pada driver untuk platform ARM . Karena ponsel biasanya dirancang di balik pintu tertutup, tim teknik di perusahaan yang berbeda sering berakhir melakukan pekerjaan rangkap, merancang perangkat keras yang pada dasarnya sama dengan pesaing mereka dan kemudian menulis driver mereka sendiri untuk desain mereka sendiri. Setelah selesai dan produk dirilis, mereka langsung bekerja untuk yang berikutnya; tidak sepadan dengan waktu mereka untuk kembali dan refactor driver untuk produk masa lalu atau menggabungkan mereka dengan driver pesaing. Hasilnya adalah sejumlah besar driver satu kali untuk perangkat yang serupa tetapi tidak persis sama.
Selain itu, smartphone biasanya didasarkan pada SOC yang memiliki perangkat keras khusus yang terintegrasi bersama dengan prosesor. Untuk sebagian dari ini, bisa jadi lebih dari masalah apakah memuat atau tidak memuat driver tertentu; kernel secara keseluruhan mungkin perlu dibangun dengan opsi konfigurasi khusus untuk berjalan pada satu SOC, yang tidak sesuai dengan opsi khusus yang diperlukan untuk dijalankan pada SOC lain.
Alasannya adalah karena kernel Linux Android umumnya tidak dikompilasi pada Android itu sendiri, melainkan harus dikompilasi silang dari komputer lain. Ini menyebabkan berbagai masalah, karena konfigurasi perangkat tidak tersedia pada waktu kompilasi, dan tidak mungkin untuk mengkompilasi kernel generik dengan semua driver karena keterbatasan ruang (sedangkan sebagian besar distro desktop hanya memiliki semua driver dikompilasi ke dalam modul yang dimuat dari initramfs) . Oleh karena itu pengembang harus mencari tahu driver mana yang harus dipaket untuk setiap perangkat tertentu. Tidak hanya itu, setiap driver umumnya memiliki selusin atau lebih opsi kompilasi waktu untuk beralih berbagai fitur driver, dan produsen biasanya tidak merilis konfigurasi resmi mereka (pelaku terburuk bahkan tidak open source driver mereka, atau tidak menjaga upstream itu salinan driver terbaru).
Pemrograman driver jauh lebih sulit daripada pemrograman aplikasi, karena tidak ada kernel yang melindungi Anda dari perangkat keras yang berubah-ubah yang memiliki persyaratan waktu real-time spesifik dan semacamnya, dan ini berarti bahkan memiliki karakteristik kinerja yang berbeda dapat menyebabkan pengemudi ketinggalan beberapa peristiwa waktu nyata yang sulit dari perangkat keras; kesalahan ini dapat muncul sebagai bug atau masalah kinerja.
Masalah lainnya adalah ketidakcocokan biner. Ada dua penyebab ketidakcocokan biner, pertama adalah tipe CPU, yang telah dicakup dengan baik oleh t0mm13b, tetapi masalah lain yang lebih relevan untuk porting adalah ketidakcocokan ABI (aplikasi binary interface). Jika pabrikan tidak membuka sumber driver mereka, maka pengembang harus menggunakan modul yang dikompilasi dari ROM stok. Ini menimbulkan berbagai masalah ketidakcocokan ABI, karena modul driver itu sendiri memiliki harapan khusus tentang, misalnya, susunan tata letak dan parameter fungsi panggilan, dan ketika kernel dikompilasi, itu tidak memiliki file header untuk menggambarkan ABI pada saat driver dikompilasi, jadi pengembang harus merekayasa balik driver untuk membuat file header atau file header di pohon sumber mungkin telah banyak dimodifikasi karena driver dikompilasi dan pengembang harus mengembalikan modifikasi tersebut untuk membuat kernel kembali kompatibel dengan ABI driver. Tidak seperti kompilasi dari sumber, kompilasi untuk driver biner tidak akan memicu kesalahan kompilasi karena parameter fungsi tidak cocok atau ketidakcocokan struct, itu hanya akan crash perangkat Anda saat sedang berjalan, dan debugging masalah ini sangat sulit. Di dunia PC, kita terbiasa dengan kekacauan yang ditinggalkan nVidia dan ATi, karena desakan mereka untuk merilis driver biner saja, bayangkan memiliki kekacauan itu untuk semua driver, bayangkan "kesenangan" yang diciptakannya.
Perangkat keras PC umumnya memiliki standar yang lebih baik daripada perangkat keras seluler, sebagian besar PC tidak memerlukan driver untuk vibrator, akselerometer, giroskop, radio 3G, sensor jarak, NFC, dll. Bahkan pada perangkat yang memiliki 3G, biasanya perangkat terhubung dengan perangkat keras menggunakan standar. koneksi seperti PCMCIA atau PCI-E.
Yah .... driver dan kernelnya tidak persis sama.
Driver adalah yang mengendalikan antena sel, wifi, bluetooth, dll. Ini adalah driver berpemilik karena produsen harus menciptakan cara (driver) untuk berbicara dengan perangkat keras mereka.
Kernel adalah tingkat perantara antara OS / aplikasi dan driver yang sebenarnya (atau cpu atau memori atau perangkat keras lainnya). Inilah yang memungkinkan OS / aplikasi Anda berinteraksi dengan komponen perangkat keras ini.
Jutaan kernel yang Anda lihat benar-benar tidak jauh berbeda satu sama lain. Biasanya seorang programmer / modder akan mengambil kernel yang ada dan "tweak" untuk mencoba dan mendapatkan perbedaan kinerja darinya. Anda pada dasarnya dapat mengatakan bahwa mereka hanya menyesuaikan (sebagian besar) "konfigurasi" dari kernel. Di dunia Android, modder ini terutama melihat: over atau underclocking jam CPU (penting untuk menghemat masa pakai baterai atau mencoba menjalankan sebagian besar aplikasi proses yang intensif seperti emulator permainan video atau pemutaran video), atau mereka melihat di bawah volting (untuk menghemat masa pakai baterai dengan menjalankan CPU Anda di luar parameter set aslinya ... yang berbeda-beda pada setiap orang karena tidak ada dua CPU yang 100% persis sama).
Ponsel dan embedded lainnya tidak memiliki BIOS untuk memberikan abstraksi antara perangkat keras dan OS sebagai akibatnya OS dikompilasi untuk perangkat keras yang digunakan. Bahkan perangkat yang menggunakan set chip yang sama dapat dikonfigurasi dengan cara yang berbeda (menggunakan bus comms alternatif, dll.) \ Hasilnya adalah bahwa kernel harus dikompilasi sesuai dengan itu. Karena tidak ada harapan perubahan pada perangkat keras, maka tidak ada deteksi perangkat keras yang dilakukan. Kernel melakukan booting lebih cepat dan lebih kecil sebagai hasilnya - ini adalah prinsip standar OS yang disematkan
CentOS diinstal pada perangkat keras yang berbeda, tetapi,
Adapun poin kedua Anda, lihat jawaban yang diposting sebelumnya.