Kami baru-baru ini mewawancarai eng.stk, pengembang kernel blu_spark. Pada bagian ini, kami bertanya kepadanya tentang asal usul dan pekerjaan pengembangannya.
Saya baru-baru ini mendapat kesempatan untuk mewawancarai Anggota Senior XDA bahasa Inggris.stk, pengembang kernel blu_spark. Ini tersedia di banyak perangkat di forum kami, termasuk Nexus 5, OnePlus 3/T, dan OnePlus 5T. Pada bagian ini, kami bertanya kepada eng.stk tentang asal usulnya dalam pengembangan dan bagaimana dia mengembangkan kernel blu_spark.
Jadi pertama-tama, perkenalkan diri Anda dan kernel Anda. Bagaimana kernel Anda membedakan dirinya dari kompetitor? Apa filosofi desain Anda untuk perubahan kernel, dan bagaimana Anda melakukannya?
Saya eng.stk dan saya sudah ada di XDA sejak 2010. Sebagian besar dari Anda mengenal saya dari proyek code_blue dan blu_spark saya :)
Saya memulai XDA dengan menulis beberapa skrip dan berbagai alat, peretasan kerangka kerja. Aku juga telah melakukan banyak tema... Selama saya di sini saya juga berkolaborasi langsung dengan beberapa proyek seperti Purity ROM, Universal Kernel Manager, Kernel Adiutor dan yang terbaru Magisk dan
Penjaga Kawat hanya untuk beberapa nama. Saya juga telah melakukan beberapa pekerjaan TWRP akhir-akhir ini (terutama pada perangkat OnePlus), modul Magisk, dan alat/peretasan lainnya [yang] berguna selama siklus hidup proyek kernel saya (beberapa hal masuk ke Portal XDA jika saya ingat benar). Kernel blu_spark mulai menjadi tidak hanya sebuah kernel, tetapi juga pengalaman menyeluruh antara kernel, rantai alat, pemulihan, tema, alat, skrip, dll. Tetapi pekerjaan kernel adalah hal yang paling saya nikmati dan mendorong saya.Saya selalu menikmati meretas dan membuat beberapa kode/skrip ketika saya punya kesempatan (membongkar mainan elektronik dan pengkodean dasar pada Commodore 64 milik sepupu saya sangat menyenangkan). Bagi saya coding bukanlah alat untuk mencapai tujuan tetapi hanya alat seperti alat lainnya untuk mencapai tujuan yang ditentukan. Sebagian besar pekerjaan saya yang lebih serius dan fondasi pekerjaan saya selesai ketika saya menemukan Linux pada masa remaja/awal usia dua puluhan. Kemudian, pada masa kuliah, Android adalah langkah logis berikutnya bagi saya: mimpi seorang pengotak-atik, dimana perangkat keras atau perangkat lunak dapat dimainkan dengan banyak hal.
Kata terbaik untuk menggambarkan blu_spark adalah optimasi dan stabilitas. Orang yang menggunakannya tahu bahwa mereka dapat mengandalkannya. Pembuatan kernel saya agak 'kekar' sehingga saya cenderung tidak menghapus beberapa barang yang sudah tersedia, menjaga semuanya opsional sehingga orang dapat memilih. Saya tidak suka menambahkan terlalu banyak hal, saya hanya mengubah atau menambahkan apa yang saya anggap terbaik untuk setiap bidang tertentu. Driver frekuensi CPU, penjadwal IO, protokol jaringan, sistem file, dll. Atau sesuaikan beberapa merdu untuk beberapa parameter tertentu atau upstream beberapa driver untuk hasil terbaik. Saya juga membuat rantai alat yang dibuat khusus (dari Linaro, versi GCC yang luar biasa), terutama untuk mendapatkan yang terbaik dari arsitekturnya.
Intinya, kebanyakan orang tahu bahwa mereka menggunakan blu_spark sejak mereka mem-flash kernel pada perangkat. Saya selalu mencari hal-hal baru dan cara untuk memberikan UX terbaik. Dengan aman.
Beritahu kami tentang gubernur blu_active Anda! Apa itu, apa fungsinya, dan mengapa istimewa?
Saya tahu terkadang orang bingung antara blu_active dengan blu_spark. blu_active hanyalah sebagian kecil dibandingkan seluruh [pekerjaan] lainnya yang saya lakukan.
Gubernur CPU pada dasarnya mengambil keputusan untuk menaikkan atau menurunkan frekuensi CPU, sesuai dengan kebutuhan sistem. Gubernur sudah beberapa kali mengalami perubahan dan mutasi sejak awal berdirinya. Seperti semua hal lain yang saya lakukan, saya membutuhkan sesuatu yang memenuhi kebutuhan saya. Hal ini didasarkan pada gubernur favorit saya, gubernur interaktif. Pada awalnya saya hanya memasukkan beberapa hal upstream ke dalamnya, tapi kemudian saya mulai menambahkan beberapa hal lain, seperti pembaruan CAF atau logika yang saya lihat di gubernur lain yang menurut saya berguna. Saya juga menambahkan kompatibilitas HMP dan beberapa kelebihan lainnya.
Iterasi terbaru didasarkan pada cabang Google Linux 4.4 Android, dengan beberapa perbaikan upstream dan CAF juga, tetapi jauh lebih ramping dari sebelumnya. Cukup gunakan apa yang Anda miliki secara maksimal, hilangkan apa yang tidak Anda miliki. Saya selalu berusaha mendapatkan baterai yang lebih baik dibandingkan dengan pengaturan stok, mengurangi pengurasan, sambil mencoba meningkatkannya performa (performa kehidupan nyata, yang Anda rasakan dengan mata dan jari, bukan dengan sintetis peralatan).
Pada suatu saat, saya ingin merdu yang sederhana sehingga orang dapat bermain-main dengan performa dengan cara yang sederhana. Beginilah cara Fastlane lahir :). Logikanya agak mirip dengan cara kerja Honda VTEC: bermain-main dengan timing dari ambang batas tertentu. Jadi, dengan peralihan sederhana dan nilai ambang batas variabel, orang dapat memiliki penskalaan frekuensi CPU yang lebih langsung dan agresif. Membuatnya masuk cepat atau lambat sesuai dengan beban sistem, melewati beban target. Ini sepenuhnya kompatibel dengan HMP dan dapat disesuaikan per cluster sesuai dengan kebutuhan pengguna, disesuaikan dengan setiap perangkat yang menjalankannya.
Mekanisme atau penyesuaian bawaan apa yang Anda suka/tidak suka yang disediakan OEM? yaitu peningkatan input Qualcomm.
Beberapa peningkatan ruang pengguna dan penyesuaian lainnya yang diatur dalam HAL (Lapisan Abstraksi Perangkat Keras), kerangka kerja yang dikodekan keras, dll, terkadang dapat mengganggu. Tentu saja, pengembang kernel diketahui dapat mengatasi beberapa masalah tersebut. Pada Nexus 5, misalnya, sebagian besar dari kita membuang mpdecision dan mendapatkan hotplug khusus - kami memiliki blu_plug pada saat itu. Beberapa perangkat lain memiliki manajemen termal yang buruk dan kontrol termal khusus dengan sysfs untuk tingkat suhu, frekuensi mitigasi, dll. Beberapa perangkat yang lebih baru memiliki beberapa kebijakan keras mengenai baterai, mencabut inti, dan hal-hal lain dalam "tingkat rendah" yang tidak memberikan keuntungan nyata dalam penggunaan perangkat. Faktanya, hal ini terkadang merusak pengalaman pengguna, jadi teknologi CTL dan BCL perlu dijinakkan.
Saya juga ingat menghapus enkripsi di perangkat ketika hal itu terjadi, semua perubahan iterasi SELinux memperkenalkan perubahan yang membuat peretasan sebelumnya dilakukan bekerja dengan cara yang berbeda... beberapa perubahan keamanan Android terkini merupakan tantangan yang terus-menerus. Ini termasuk AVB (beberapa bagian kebanyakan dikenal sebagai dm-verity). Beberapa perubahan lain telah membuat pembatasan tempat merdu dan sysfs harus dipindahkan karena kami tidak memiliki akses ke tempat yang sama seperti sebelumnya. Sebagian besar pembatasan ini lebih relevan untuk ROM stok (tempat saya melakukan sebagian besar pekerjaan saya), biasanya ini membuka jalan dan mempermudah dalam hal ROM khusus (yang pembatasannya lebih rendah).
Pada SoC terbaru seperti Qualcomm Snapdragon 820 dan 835, beberapa OEM telah menambahkan beberapa peningkatan dari ruang pengguna yang diterima dan mengatasi titik buta dalam sistem, tidak semua hal OEM buruk. Terkait sumber kernel, semakin bersih dan terdokumentasikan sumbernya, semakin baik.
Fitur lain apa yang ingin Anda sertakan? Seperti kontrol warna tingkat lanjut, dan lain sebagainya.
Saya biasanya tidak menyertakan hal-hal yang tidak saya gunakan secara pribadi atau yang menurut saya tidak berguna. Hal-hal yang ingin saya lakukan, selain blu_active, termasuk pengoptimalan dan perbaikan arsitektur, pembaruan hal-hal kripto, penjadwalan IO, dan lainnya perlengkapan penyimpanan/sistem file, KCAL, pengisian cepat USB, kekuatan getaran, kontrol LED baterai/notifikasi, pemblokir Wakelock, WireGuard, dll. Saya selalu membangun dengan rantai alat yang dibuat khusus seperti yang saya katakan sebelumnya.
Metodologi pengujian apa yang Anda gunakan untuk kernel Anda? Apakah Anda menggunakan laporan pengguna, atau tolok ukur, atau rutinitas khusus lainnya?
Saya memiliki setiap ponsel yang saya kembangkan, jadi setiap perubahan selalu diuji oleh saya. Karena saya setiap hari mengendarai setiap perangkat untuk jangka waktu yang lama, apa pun yang menurut saya tidak cocok untuk saya, seharusnya tidak cocok untuk orang lain. Saat saya merilis sebuah build secara publik, build tersebut sudah melalui banyak pengujian dari saya dan beberapa orang lain yang saya percayai dapat memberikan masukan yang berguna. Saya tahu terkadang beberapa pengguna bosan karena terus-menerus membuat segala sesuatunya berjalan sebagaimana mestinya, namun saya menghargai stabilitas di atas segalanya: Saya selalu menempatkan diri saya pada posisi pengguna di tempat pertama.
Saya menjalankan berbagai hal berdasarkan kasus penggunaan kehidupan nyata, bukan pengujian sintetis. Perangkat lunak semacam ini dibuat untuk manusia, bukan mesin di back office. Titik awalnya selalu lebih baik daripada pengalaman saham, di semua sisi, tapi saya tidak terlalu menghargai skor tinggi Antutu terbaru. Kernel saya dapat disesuaikan dengan tolok ukur semacam ini, tetapi itu bukan tujuan akhir saya. Saya menghargai beberapa tolok ukur yang lebih langsung, seperti pengujian penyimpanan IO misalnya. Misalnya, mereka dapat memberikan cara cepat untuk menyatakan beberapa perubahan yang baru saja dilakukan.
Saya melakukan pengujian dengan ROM stok sehingga saya dapat memiliki dasar yang stabil untuk berbagai hal. Saya melakukan pembuatan khusus untuk ROM khusus, namun karena sifat mudah berubah dari ROM khusus dengan tambahan tambahan, nightlies, dan bahkan perbedaan implementasi pada beberapa fitur, tidak mungkin untuk mencakup semuanya dan memberikan dukungan yang tepat kepada semua orang, Sayangnya.
Saya juga terkadang membuat versi beta untuk menguji sesuatu yang spesifik atau ketika saya meluncurkan versi ke ROM Beta atau pratinjau pengembang. Saya melakukan itu pada perangkat Nexus dan OnePlus, terkadang orang suka menguji berbagai hal :)
Lihat bagian 2: F2FS, EAS dan Tip untuk Calon Pengembang Kernel