Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Gambar Kernel Generik

Kernel Umum Android (ACK) adalah dasar untuk semua kernel produk Android. Vendor dan kernel perangkat adalah bagian hilir ACK. Vendor menambahkan dukungan untuk SoC dan perangkat periferal dengan memodifikasi kode sumber kernel dan menambahkan driver perangkat. Modifikasi ini bisa ekstensif, sampai-sampai sebanyak 50% kode yang berjalan pada perangkat adalah kode di luar pohon (bukan dari Linux hulu atau dari kernel umum AOSP).

Jadi, kernel perangkat terdiri dari:

  • Upstream: Kernel Linux dari kernel.org
  • AOSP: Tambalan khusus Android tambahan dari kernel umum AOSP
  • Vendor: SoC dan pengaktifan periferal serta patch pengoptimalan dari vendor
  • OEM / perangkat: Driver dan kustomisasi perangkat tambahan

Hampir setiap perangkat memiliki kernel khusus. Ini adalah fragmentasi kernel.

Hierarki kernel Android mengarah ke fragmentasi

Gambar 1. Hierarki kernel Android mengarah ke fragmentasi

Biaya fragmentasi

Fragmentasi kernel memiliki beberapa efek negatif pada komunitas Android.

Pembaruan keamanan padat karya

Patch keamanan yang dikutip di Android Security Bulletin (ASB) harus di-backport ke setiap kernel perangkat. Namun, karena fragmentasi kernel, sangat mahal untuk menyebarkan perbaikan keamanan ke perangkat Android di lapangan.

Sulit untuk menggabungkan pembaruan yang Didukung Jangka Panjang

Rilis Long-Term Supported (LTS) mencakup perbaikan keamanan dan perbaikan bug kritis lainnya. Tetap up to date dengan rilis LTS telah terbukti menjadi cara paling efektif untuk memberikan perbaikan keamanan. Pada perangkat Pixel, ditemukan bahwa 90% masalah keamanan kernel yang dilaporkan di ASB telah diperbaiki untuk perangkat yang selalu diperbarui.

Namun, dengan semua modifikasi khusus di kernel perangkat, sulit untuk hanya menggabungkan perbaikan LTS ke dalam kernel perangkat.

Menghambat peningkatan versi rilis platform Android

Fragmentasi mempersulit fitur Android baru yang memerlukan perubahan kernel untuk ditambahkan ke perangkat di lapangan. Kode Kerangka Android harus mengasumsikan bahwa sebanyak lima versi kernel didukung dan tidak ada perubahan kernel yang dibuat untuk rilis platform baru (Android 10 mendukung kernel 3.18, 4.4, 4.9, 4.14, dan 4.19, yang dalam beberapa kasus belum pernah dilakukan. ditingkatkan dengan fitur baru sejak Android 8 pada 2017).

Sulit untuk memberikan kontribusi perubahan kernel kembali ke Linux hulu

Dengan semua perubahan yang dilakukan pada kernel, sebagian besar perangkat andalan dikirimkan dengan versi kernel yang sudah berusia setidaknya 18 bulan. Misalnya, kernel 4.14 dirilis oleh kernel.org pada November 2017 dan ponsel Android pertama yang menggunakan kernel 4.14 dikirim pada Musim Semi 2019.

Penundaan yang lama antara rilis kernel dan produk upstream ini menyulitkan komunitas Android untuk memasukkan fitur dan driver yang diperlukan ke dalam kernel upstream, sehingga memperbaiki masalah fragmentasi menjadi tantangan.

Memperbaiki fragmentasi: Gambar Kernel Generik

Proyek Generic Kernel Image (GKI) menangani fragmentasi kernel dengan menyatukan kernel inti dan memindahkan SoC dan dukungan papan dari kernel inti ke modul yang dapat dimuat. Kernel GKI menghadirkan Kernel Module Interface (KMI) yang stabil untuk modul kernel, sehingga modul dan kernel dapat diperbarui secara independen.

GKI:

  • Dibangun dari sumber ACK.
  • Merupakan biner kernel tunggal plus modul terkait yang dapat dimuat per arsitektur, per rilis LTS (saat ini hanya arm64 untuk android11-5.4 dan android12-5.4 ).
  • Diuji dengan semua rilis Platform Android yang didukung untuk ACK terkait. Tidak ada penghentian fitur seumur hidup versi kernel GKI
  • Memaparkan KMI yang stabil ke driver dalam LTS tertentu.
  • Tidak berisi kode khusus SoC atau papan.

Berikut tampilan perangkat Android dengan penerapan GKI.

Arsitektur GKI

Gambar 2. Arsitektur GKI

GKI adalah perubahan kompleks yang akan diluncurkan dalam beberapa tahap dimulai dengan kernel v5.4 pada rilis platform Android 11.

GKI 1.0 - Persyaratan kompatibilitas GKI

Untuk beberapa perangkat yang diluncurkan dengan rilis platform Android 11, kompatibilitas Treble memerlukan pengujian GKI untuk perangkat yang menjalankan kernel v5.4.

Partisi untuk pengujian kompatibilitas GKI

Gambar 3. Partisi untuk pengujian kompatibilitas GKI

Kompatibilitas GKI berarti perangkat lolos pengujian VTS dan CTS-on-GSI + GKI dengan Generic System Image (GSI) dan kernel GKI yang diinstal dengan mem-flash image boot GKI ke partisi boot dan image sistem GSI di partisi system . Perangkat dapat dikirimkan dengan kernel produk yang berbeda dan dapat menggunakan modul yang dapat dimuat yang tidak disediakan oleh GKI. Namun, kernel produk dan GKI harus memuat modul dari partisi vendor_boot dan vendor sama. Oleh karena itu, semua kernel produk harus memiliki antarmuka modul kernel biner (KMI) yang sama. Vendor dapat memperpanjang KMI untuk kernel produk selama masih sesuai dengan GKI KMI. Tidak ada persyaratan bahwa modul vendor dapat dibongkar di GKI 1.0.

GKI 1.0 gol

  • Jangan memperkenalkan regresi di VTS atau CTS saat kernel produk diganti dengan kernel GKI.
  • Kurangi beban pemeliharaan kernel untuk OEM dan vendor agar selalu terbarui dengan kernel umum AOSP.
  • Sertakan perubahan inti Android di kernel baik perangkat diupgrade ke rilis platform Android baru atau yang baru diluncurkan.
  • Jangan pernah merusak ruang pengguna Android.
  • Pisahkan komponen khusus perangkat keras dari kernel inti sebagai modul yang dapat dimuat.

GKI 2.0 - Produk GKI

Beberapa perangkat yang diluncurkan dengan rilis platform Android 12 (2021) menggunakan versi kernel v5.10 atau lebih tinggi harus dikirimkan dengan kernel GKI. Gambar boot yang ditandatangani akan tersedia dan diperbarui secara berkala dengan LTS dan perbaikan bug penting. Karena stabilitas biner akan dipertahankan untuk KMI, image boot ini dapat diinstal tanpa mengubah image vendor.

GKI 2.0 gol

  • Jangan memperkenalkan kinerja atau regresi kekuasaan yang signifikan dengan GKI.
  • Aktifkan OEM untuk mengirimkan perbaikan keamanan kernel dan perbaikan bug (LTS) tanpa keterlibatan vendor.
  • Mengurangi biaya pembaruan versi kernel utama untuk perangkat (misalnya, dari v5.10 ke kernel LTS 2021).
  • Pertahankan hanya satu biner kernel GKI per arsitektur dengan memperbarui versi kernel dengan proses yang jelas untuk peningkatan.

Desain GKI

Cabang kernel KMI

Kernel GKI dibuat dari cabang kernel ACK KMI, yang dijelaskan secara mendetail di Android Common Kernels . KMI diidentifikasi secara unik oleh versi kernel dan rilis platform Android, sehingga cabang-cabangnya diberi nama <androidRelease>-<kernel version> . Misalnya, cabang kernel 5.4 KMI untuk Android 11 diberi nama android11-5.4. Diharapkan untuk Android 12 (tidak berkomitmen dan hanya ditampilkan untuk menunjukkan bagaimana model percabangan baru akan berkembang di masa mendatang) akan ada dua kernel KMI tambahan, android12-5.4 dan kernel kedua berdasarkan kernel LTS baru, yang seharusnya dideklarasikan pada akhir tahun 2020.

Hierarki kernel KMI

Gambar 4 menunjukkan hierarki cabang untuk 5.10 kernel KMI. android12-5.10 adalah kernel KMI yang sesuai dengan Android 12 dan android13-5.10 sesuai dengan Android T (eksperimental AOSP) (tidak berkomitmen dan hanya ditampilkan untuk mendemonstrasikan bagaimana kemajuan model percabangan baru di masa mendatang).

Hierarki kernel KMI untuk 5.10

Gambar 4. Hierarki kernel KMI untuk 5.10

Seperti yang ditunjukkan pada Gambar 4, siklus cabang KMI melalui tiga fase: pengembangan (dev), stabilisasi (stab), dan pembekuan . Fase ini dijelaskan secara mendetail di Android Common Kernels .

Setelah kernel KMI dibekukan, tidak ada perubahan pemecah KMI yang diterima kecuali masalah keamanan serius teridentifikasi yang tidak dapat dikurangi tanpa mempengaruhi KMI yang stabil. Cabang tetap membeku sepanjang masa hidupnya.

Perbaikan bug dan fitur mitra dapat diterima di cabang yang dibekukan selama KMI yang ada tidak rusak. KMI dapat diperpanjang dengan simbol ekspor baru selama antarmuka yang terdiri dari KMI saat ini tidak terpengaruh. Ketika antarmuka baru ditambahkan ke KMI, mereka segera menjadi stabil dan tidak dapat rusak oleh perubahan di masa mendatang.

Misalnya, perubahan yang menambahkan bidang ke struktur yang digunakan oleh antarmuka KMI tidak diperbolehkan karena mengubah definisi antarmuka:

struct foo {
  int original_field1;
  int original_field2;
  int new_field; // Not allowed
};

int do_foo(struct foo &myarg)
{
  do_something(myarg);
}
EXPORT_SYMBOL_GPL(do_foo);

Namun, menambahkan fungsi baru tidak masalah:

struct foo_ext {
  struct foo orig_foo;
  int new_field;
};

int do_foo2(struct foo_ext &myarg)
{
  do_something_else(myarg);
}
EXPORT_SYMBOL_GPL(do_foo2);

Stabilitas KMI

Untuk mewujudkan tujuan GKI, sangat penting untuk menjaga KMI yang stabil bagi pengemudi. Kernel GKI dibangun dan dikirim dalam bentuk biner, tetapi modul yang dapat dimuat vendor dibangun di pohon terpisah. Kernel dan modul GKI yang dihasilkan harus bekerja seolah-olah mereka dibangun bersama. Untuk pengujian kompatibilitas GKI, image boot yang berisi kernel diganti dengan image boot yang berisi kernel GKI, dan modul yang dapat dimuat di image vendor harus berfungsi dengan benar dengan salah satu kernel.

KMI tidak menyertakan semua simbol di kernel atau bahkan semua dari 30.000+ simbol yang diekspor. Sebaliknya, simbol yang dapat digunakan oleh modul secara eksplisit tercantum dalam satu set file daftar simbol yang disimpan secara publik di root pohon kernel. Penyatuan semua simbol di semua file daftar simbol mendefinisikan kumpulan simbol KMI yang dipertahankan sebagai stabil. Contoh file daftar simbol adalah abi_gki_aarch64_db845c , yang mendeklarasikan simbol yang diperlukan untuk DragonBoard 845c .

Hanya simbol yang terdaftar dalam daftar simbol dan struktur serta definisinya yang terkait yang dianggap sebagai bagian dari KMI. Anda dapat memposting perubahan ke daftar simbol Anda jika simbol yang Anda butuhkan tidak ada. Setelah antarmuka baru berada dalam daftar simbol, dan oleh karena itu merupakan bagian dari deskripsi KMI, antarmuka tersebut dipertahankan stabil dan tidak boleh dihapus dari daftar simbol atau diubah setelah cabang dibekukan.

Setiap pohon kernel KMI memiliki kumpulan daftar simbolnya sendiri. Tidak ada upaya yang dilakukan untuk memberikan stabilitas ABI antara cabang kernel KMI yang berbeda. Misalnya, KMI untuk android11-5.4 sepenuhnya independen dari KMI untuk android12-5.4 .

Umumnya, komunitas Linux tidakmenyukai gagasan stabilitas ABI dalam kernel untuk kernel jalur utama. Dalam menghadapi berbagai rantai alat, konfigurasi, dan kernel jalur utama Linux yang terus berkembang, tidak mungkin untuk mempertahankan KMI yang stabil di jalur utama. Namun, hal itu mungkin terjadi di lingkungan GKI yang sangat terbatas. Kendalanya adalah:

  • KMI hanya stabil dalam kernel LTS yang sama (misalnya, android11-5.4 ).
    • Tidak ada stabilitas KMI yang dipertahankan untuk android-mainline .
  • Hanya toolchain Clang tertentu yang disediakan di AOSP dan ditentukan untuk cabang terkait yang digunakan untuk membangun kernel dan modul.
  • Hanya simbol yang diketahui digunakan oleh modul seperti yang ditentukan dalam daftar simbol yang dipantau untuk stabilitas dan dianggap sebagai simbol KMI.
    • Konsekuensinya adalah bahwa modul hanya boleh menggunakan simbol KMI. Ini dipaksakan dengan gagal memuat modul jika simbol non-KMI diperlukan.
  • Setelah cabang KMI dibekukan, tidak ada perubahan yang dapat merusak KMI, termasuk:
    • Perubahan konfigurasi
    • Perubahan kode kernel
    • Perubahan Toolchain (termasuk pembaruan)

Pemantauan KMI

Alat pemantauan ABI memantau stabilitas KMI selama pengujian pra-pengiriman. Perubahan yang merusak KMI gagal mengirimkan pengujian dan harus dikerjakan ulang agar kompatibel. Alat-alat ini tersedia untuk mitra dan publik untuk diintegrasikan ke dalam proses pembangunan mereka. Tim kernel Android menggunakan alat ini untuk menemukan kerusakan KMI selama pengembangan dan saat menggabungkan rilis LTS. Jika kerusakan KMI terdeteksi selama penggabungan LTS, KMI dipertahankan dengan menghapus patch yang menyinggung atau dengan melakukan refactoring patch agar kompatibel.

KMI dianggap rusak jika simbol KMI yang ada diubah dengan cara yang tidak sesuai. Contoh:

  • Argumen baru ditambahkan ke fungsi KMI
  • Bidang baru ditambahkan ke struktur yang digunakan oleh fungsi KMI
  • Nilai enum baru yang mengubah nilai enum yang digunakan oleh fungsi KMI
  • Perubahan konfigurasi yang mengubah keberadaan anggota data yang mempengaruhi KMI

Menambahkan simbol baru tidak selalu merusak KMI, tetapi simbol baru yang digunakan harus ditambahkan ke daftar simbol dan representasi ABI. Jika tidak, perubahan masa depan pada bagian KMI ini tidak akan dikenali.

Mitra diharapkan menggunakan alat pemantauan ABI untuk membandingkan KMI antara kernel produk mereka dan kernel GKI dan memastikan bahwa keduanya kompatibel.

Kernel GKI biner android11-5.4 terbaru dapat diunduh dari ci.android.com ( kernel_aarch64 builds).

Kompiler tunggal

Perubahan compiler dapat mengubah tata letak struktur data kernel internal yang memengaruhi ABI. Karena sangat penting untuk menjaga KMI tetap stabil, rantai alat yang digunakan untuk membangun kernel GKI harus sepenuhnya kompatibel dengan rantai alat yang digunakan untuk membangun modul vendor. Kernel GKI dibangun dengan toolchain LLVM yang termasuk dalam AOSP.

Mulai Android 10, semua kernel Android harus dibuat dengan toolchain LLVM. Dengan GKI, rantai alat LLVM yang digunakan untuk membangun kernel produk dan modul vendor harus menghasilkan ABI yang sama dengan rantai alat LLVM dari AOSP dan mitra harus memastikan bahwa KMI kompatibel dengan kernel GKI.

Dokumentasi pembuatan kernel Android menjelaskan bagaimana kernel GKI referensi dibuat. Secara khusus, prosedur terdokumentasi memastikan bahwa toolchain dan konfigurasi yang benar digunakan untuk membangun kernel. Mitra hilir didorong untuk menggunakan perkakas yang sama untuk memproduksi kernel akhir guna menghindari ketidaksesuaian yang disebabkan oleh rantai alat atau ketergantungan waktu pembuatan lainnya.

Konfigurasi kernel

Kernel GKI dibangun menggunakan arch/arm64/configs/gki_defconfig . Karena konfigurasi ini memengaruhi KMI, konfigurasi GKI dikelola dengan sangat hati-hati. Untuk kernel KMI yang dibekukan, konfigurasi hanya dapat ditambahkan atau dihapus jika tidak ada dampak pada KMI.

Kernel GKI harus dikonfigurasi untuk dijalankan pada perangkat yang beragam. Oleh karena itu, harus memiliki dukungan bawaan untuk semua subsistem dan opsi yang diperlukan untuk semua perangkat ini, tidak termasuk modul yang dapat dimuat yang digunakan untuk mengaktifkan perangkat keras. Mitra harus meminta perubahan konfigurasi yang diperlukan pada kernel dev.

Perubahan boot

Untuk memfasilitasi pemisahan yang bersih antara GKI dan komponen vendor, partisi boot hanya berisi komponen generik, termasuk kernel dan ramdisk dengan modul GKI. Versi baru dari boot header (v3) didefinisikan untuk menunjukkan kepatuhan dengan arsitektur GKI. Gambar booting versi GKI dikirimkan oleh Google dan menggantikan gambar booting versi vendor saat menguji kompatibilitas GKI.

Ramdisk untuk init tahap pertama, recovery , dan fastbootd adalah gambar initramfs terdiri dari dua arsip CPIO yang digabungkan oleh bootloader. Arsip CPIO pertama berasal dari partisi vendor_boot baru. Yang kedua berasal dari partisi boot .

Ringkasan perubahan disediakan di sini. Lihat Partisi boot vendor untuk detailnya.

Partisi boot

Partisi boot menyertakan header, kernel, dan arsip CPIO dari bagian umum dari boot ramdisk.

Dengan v3 booting sundulan boot partisi, bagian ini dari sebelum boot partisi tidak lagi hadir:

  • Bootloader tahap kedua: Jika perangkat memiliki bootloader tahap kedua, ia harus disimpan di partisinya sendiri.
  • DTB: DTB disimpan di partisi boot Vendor .

Partisi boot berisi arsip CPIO dengan komponen GKI:

  • Modul kernel GKI terletak di /lib/modules/
  • first_stage_init dan pustaka tempat bergantung
  • fastbootd dan recovery (digunakan di perangkat A / B dan Virtual A / B)

Gambar boot GKI disediakan oleh Google dan harus digunakan untuk pengujian kompatibilitas GKI .

Arm64 android11-5.4 boot.img terbaru dapat diunduh dari ci.android.com di artefak build aosp_arm64 dari cabang aosp-master .

Gambar kernel arm64 android11-5.4 terbaru ( Image.gz ) dapat diunduh dari ci.android.com di artefak pembuatan kernel_aarch64 dari cabang aosp_kernel-common-android11-5.4 .

Partisi boot vendor

Partisi vendor_boot diperkenalkan dengan GKI. Ini A / B dengan Virtual A / B dan terdiri dari sebuah header, vendor ramdisk, dan blob pohon perangkat. Ramdisk vendor adalah arsip CPIO yang berisi modul vendor yang diperlukan untuk boot perangkat. Ini termasuk modul untuk mengaktifkan fungsionalitas SoC penting serta driver penyimpanan dan tampilan yang diperlukan untuk mem-boot perangkat dan menampilkan layar splash.

Arsip CPIO berisi:

  • Modul kernel vendor init tahap pertama terletak di /lib/modules/
  • File konfigurasi modprobe terletak di /lib/modules
  • modules.load file yang menunjukkan modul-modul yang akan dimuat selama init tahap pertama

Persyaratan bootloader

Bootloader harus memuat gambar CPIO ramdisk generik (dari partisi boot ) ke dalam memori segera setelah gambar vendor_boot ramdisk vendor (dari partisi vendor_boot ). Setelah dekompresi, hasilnya adalah ramdisk generik yang dihamparkan di atas struktur file ramdisk vendor.

Pengujian kompatibilitas GKI

Untuk rilis platform Android 11, perangkat yang diluncurkan dengan kernel v5.4 harus menjalankan pengujian VTS dan CTS-on-GSI menggunakan gambar boot GKI yang disediakan oleh Google.

Berkontribusi pada kernel GKI

Kernel GKI dibangun dari AOSP Common Kernels yang dimulai dengan android11-5.4 . Semua patch yang dikirimkan harus sesuai dengan pedoman kontribusi ini , yang mendokumentasikan dua strategi:

  1. Terbaik: Lakukan semua perubahan Anda ke hulu Linux. Jika sesuai, lakukan backport ke rilis stabil. Tambalan ini digabungkan secara otomatis di kernel umum AOSP yang sesuai. Jika patch sudah ada di Linux upstream, posting backport patch yang sesuai dengan persyaratan patch di bawah.
  2. Kurang bagus: Kembangkan patch Anda dari pohon (dari sudut pandang Linux hulu). Kecuali jika tambalan memperbaiki bug khusus Android, tambalan tersebut kemungkinan besar tidak akan diterima kecuali telah dikoordinasikan dengan kernel-team@android.com .

Untuk mitra pelaksana GKI, mungkin ada alasan yang valid mengapa patch di luar pohon diperlukan (terutama jika ada jadwal silikon yang harus dipenuhi). Untuk kasus ini, ajukan masalah Buganizer .

Kirimkan perubahan GKI melalui Gerrit ke android-mainline branch terlebih dahulu, lalu lakukan backport ke cabang rilis lain sesuai kebutuhan.

Kode sumber yang terkait dengan modul yang dapat dimuat tidak perlu dikontribusikan ke pohon sumber kernel GKI, namun sangat disarankan untuk mengirimkan semua driver ke Linux hulu.

Meminta backport dari jalur utama

Umumnya patch jalur utama yang dibutuhkan oleh mitra GKI dapat di-backport ke kernel GKI. Unggah tambalan ke Gerrit mengikuti pedoman kontribusi .

Jika patch telah diposting ke upstream, tetapi belum diterima, disarankan untuk menunggu hingga diterima. Jika jadwal tidak mengizinkan menunggu patch diterima di upstream, ajukan masalah Buganizer.

Menambah dan menghapus konfigurasi GKI

Untuk meminta penambahan atau penghapusan konfigurasi di arch/arm64/configs/gki_defconfig , ajukan masalah Buganizer dengan jelas menyatakan permintaan dan pembenarannya. Jika tidak ada proyek Buganizer yang dapat diakses, posting tambalan dengan perubahan konfigurasi ke Gerrit dan pastikan pesan komit dengan jelas menyatakan alasan mengapa konfigurasi tersebut diperlukan.

Perubahan konfigurasi pada kernel KMI yang dibekukan tidak boleh memengaruhi KMI.

Mengubah kode inti kernel

Modifikasi kode kernel inti di kernel umum AOSP tidak disarankan. Pertama, kirim tambalan ke upstream Linux dan kemudian lakukan backport. Jika ada alasan bagus untuk perubahan kernel inti, ajukan masalah Buganizer dengan jelas menyatakan permintaan dan pembenarannya. Tidak ada fitur khusus Android yang diterima tanpa masalah Buganizer. Kirim email ke kernel-team@android.com jika Anda tidak dapat membuat masalah Buganizer.

Mengekspor simbol menggunakan melalui EXPORT_SYMBOL_GPL ()

Jangan mengirim tambalan ke hulu yang hanya berisi ekspor simbol. Untuk dipertimbangkan untuk Linux upstream, penambahan EXPORT_SYMBOL_GPL() memerlukan driver modular di dalam pohon yang menggunakan simbol tersebut, jadi sertakan driver baru atau perubahan ke driver yang sudah ada di patchset yang sama dengan ekspor.

Saat mengirim patch ke upstream, pesan commit harus berisi justifikasi yang jelas mengapa patch diperlukan dan bermanfaat bagi komunitas. Mengaktifkan ekspor untuk mendapatkan keuntungan dari driver atau fungsionalitas out-of-tree bukanlah argumen yang meyakinkan bagi pengelola upstream.

Jika karena alasan tertentu, tambalan tidak dapat dikirim ke hulu, ajukan masalah Buganizer dan jelaskan mengapa tambalan tidak dapat dikirim ke hulu. Umumnya, simbol yang merupakan antarmuka yang didukung ke subsistem kernel cenderung diterima sebagai ekspor. Namun, fungsi pembantu internal acak kemungkinan tidak akan diterima dan Anda akan diminta untuk memfaktorkan ulang kode Anda untuk menghindari penggunaannya.

Menambahkan simbol ke daftar simbol KMI

Daftar simbol KMI harus diperbarui dengan simbol kernel GKI yang digunakan oleh modul vendor. Karena hanya simbol KMI yang dipertahankan stabil, GKI tidak mengizinkan modul dimuat jika mereka mengandalkan simbol non-KMI.

Script extract_symbols mengekstrak simbol yang relevan dari kernel build tree dan dapat digunakan untuk memperbarui daftar simbol KMI. Lihat dokumentasi daftar simbol untuk detail lebih lanjut.