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

Gambar Kernel Umum

The Android umum Kernel (ACK) merupakan dasar untuk semua kernel produk Android. Vendor dan kernel perangkat berada di hilir ACK. Vendor menambahkan dukungan untuk SoC dan perangkat periferal dengan memodifikasi kode sumber kernel dan menambahkan driver perangkat. Modifikasi ini dapat luas, ke titik bahwa sebanyak 50% dari kode yang berjalan pada perangkat adalah out-of-pohon kode (bukan dari hulu Linux atau dari AOSP kernel umum).

Dengan demikian, kernel perangkat terdiri dari:

  • Hulu: Kernel Linux dari kernel.org
  • AOSP: Patch khusus Android tambahan dari kernel umum AOSP
  • Vendor: SoC dan pemberdayaan periferal dan patch pengoptimalan dari vendor
  • OEM/perangkat: Driver dan penyesuaian perangkat tambahan

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

Hirarki kernel Android mengarah ke fragmentasi

Gambar 1. Android hirarki kernel mengarah ke fragmentasi

Biaya fragmentasi

Fragmentasi kernel memiliki beberapa efek negatif pada komunitas Android.

Pembaruan keamanan bersifat padat karya

Patch keamanan dikutip dalam Android Security Bulletin (ASB) harus backported ke masing-masing 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

Jangka Panjang Didukung (LTS) rilis termasuk perbaikan keamanan dan perbaikan bug penting lainnya. Tetap up to date dengan rilis LTS telah terbukti menjadi cara paling efektif untuk memberikan perbaikan keamanan. Pada perangkat Pixel, ditemukan bahwa 90% dari masalah keamanan kernel yang dilaporkan di ASB telah diperbaiki untuk perangkat yang tetap up to date.

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

Menghambat peningkatan rilis platform Android

Fragmentasi mempersulit fitur Android baru yang membutuhkan perubahan kernel untuk ditambahkan ke perangkat di lapangan. Kode Kerangka Kerja 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 ditingkatkan dengan fitur baru sejak Android 8 pada 2017).

Sulit untuk mengkontribusikan perubahan kernel kembali ke Linux hulu

Dengan semua perubahan yang dilakukan pada kernel, sebagian besar perangkat unggulan dikirimkan dengan versi kernel yang sudah berusia minimal 18 bulan. Sebagai contoh, 4.14 kernel dirilis oleh kernel.org pada bulan November 2017 dan ponsel Android pertama yang menggunakan 4.14 kernel dikirimkan pada musim semi 2019.

Penundaan yang lama antara rilis kernel upstream dan produk mempersulit komunitas Android untuk memasukkan fitur dan driver yang dibutuhkan ke kernel upstream, sehingga sulit untuk memperbaiki masalah fragmentasi.

Memperbaiki fragmentasi: Gambar Kernel Generik

Generic Kernel Image (GKI) alamat proyek kernel fragmentasi dengan menyatukan kernel inti dan bergerak SoC dan dukungan dewan dari kernel inti dalam modul loadable. GKI kernel hadiah yang stabil Kernel Module Interface (KMI) untuk modul kernel, sehingga modul dan kernel dapat diperbarui secara independen.

GKI:

  • Dibangun dari sumber ACK.
  • Adalah satu-kernel biner ditambah terkait modul loadable 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 selama masa pakai versi kernel GKI
  • Mengekspos stabil KMI untuk driver dalam LTS diberikan.
  • Tidak mengandung SoC- atau kode papan khusus.

Berikut tampilan perangkat Android dengan penerapan GKI.

arsitektur GKI

Arsitektur Gambar 2. GKI

GKI adalah perubahan kompleks yang akan diluncurkan dalam beberapa tahap dimulai dengan kernel v5.4 dalam 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 GKI pengujian kompatibilitas

GKI kompatibilitas berarti bahwa perangkat melewati VTS dan CTS-on-GSI tes + GKI dengan Generic System Image (GSI) dan kernel GKI diinstal oleh flashing GKI boot image ke dalam boot partisi dan gambar sistem GSI di system partisi. Perangkat dapat kapal dengan kernel produk yang berbeda dan dapat menggunakan modul loadable bahwa GKI tidak menyediakan. Namun, baik produk dan kernel GKI harus memuat modul dari yang sama vendor_boot dan vendor partisi. Oleh karena itu, semua kernel produk harus memiliki antarmuka modul kernel biner (KMI) yang sama. Vendor dapat memperpanjang KMI untuk kernel produk selama masih kompatibel dengan GKI KMI. Tidak ada persyaratan bahwa modul vendor tidak dapat dimuat di GKI 1.0.

GKI 1.0 tujuan

  • Jangan memperkenalkan regresi di VTS atau CTS saat kernel produk diganti dengan kernel GKI.
  • Kurangi beban pemeliharaan kernel untuk OEM dan vendor agar tetap up to date dengan kernel umum AOSP.
  • Sertakan perubahan inti Android dalam kernel baik perangkat diupgrade ke rilis platform Android baru atau 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 Android 12 (2021) rilis platform menggunakan versi kernel v5.10 atau lebih tinggi diperlukan untuk kapal 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 perubahan pada image vendor.

GKI 2.0 tujuan

  • Jangan perkenalkan kinerja atau regresi kekuatan yang signifikan dengan GKI.
  • Aktifkan OEM untuk memberikan perbaikan keamanan kernel dan perbaikan bug (LTS) tanpa keterlibatan vendor.
  • Kurangi 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 upgrade yang jelas.

desain GKI

Cabang kernel KMI

GKI kernel dibangun dari cabang kernel ACK KMI, yang dijelaskan secara rinci di Android Umum Kernel . The KMI unik diidentifikasi oleh versi kernel dan rilis platform Android, sehingga cabang-cabang yang bernama <androidRelease>-<kernel version> . Sebagai contoh, 5,4 cabang kernel KMI untuk Android 11 bernama android11-5.4. Itu diharapkan bahwa untuk Android 12 (tidak berkomitmen dan hanya ditampilkan untuk menunjukkan bagaimana model percabangan baru akan maju di masa depan) akan ada dua tambahan KMI kernel, android12-5.4 dan kernel kedua berdasarkan 5.10 LTS kernel, dirilis pada bulan Desember 2020.

Hirarki kernel KMI

Gambar 4 menunjukkan hierarki cabang untuk kernel 5.10 KMI. android12-5.10 adalah kernel KMI sesuai dengan Android 12 dan android13-5.10 bersesuaian dengan Android T (AOSP percobaan) (tidak berkomitmen dan hanya ditampilkan untuk menunjukkan bagaimana model percabangan baru akan maju di masa depan).

Hirarki kernel KMI untuk 5.10

Hirarki Gambar 4. KMI kernel untuk 5.10

Seperti ditunjukkan dalam Gambar 4, KMI cabang siklus melalui tiga tahap: pengembangan (dev), stabilisasi (menusuk), dan beku. Fase ini dijelaskan secara rinci dalam Android umum Kernel .

Setelah kernel KMI dibekukan, tidak ada perubahan yang melanggar KMI yang diterima kecuali masalah keamanan serius diidentifikasi yang tidak dapat dikurangi tanpa mempengaruhi KMI yang stabil. Cabang tetap beku sepanjang hidupnya.

Perbaikan bug dan fitur mitra dapat diterima ke cabang beku 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 dilanggar 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 dibuat dan dikirimkan dalam bentuk biner, tetapi modul yang dapat dimuat oleh vendor dibuat dalam struktur 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 dalam 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. Sebagai gantinya, simbol yang dapat digunakan oleh modul secara eksplisit terdaftar dalam satu set file daftar simbol yang dikelola secara publik di akar pohon kernel. Penyatuan semua simbol di semua file daftar simbol mendefinisikan kumpulan simbol KMI yang dipertahankan sebagai stabil. Contoh daftar simbol file abi_gki_aarch64_db845c , yang menyatakan simbol diperlukan untuk 845c DragonBoard .

Hanya simbol yang tercantum dalam daftar simbol dan struktur serta definisi 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 sebagai stabil dan tidak boleh dihapus dari daftar simbol atau dimodifikasi 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. Sebagai contoh, KMI untuk android11-5.4 benar-benar independen dari KMI untuk android12-5.4 .

Umumnya, komunitas Linux telah mengerutkan kening pada gagasan stabilitas ABI di-kernel untuk kernel utama. Dalam menghadapi berbagai toolchain, konfigurasi, dan kernel Linux arus utama yang terus berkembang, mempertahankan KMI yang stabil di saluran utama tidak mungkin dilakukan. Namun, itu mungkin di lingkungan GKI yang sangat terbatas. Kendalanya adalah:

  • The KMI hanya stabil dalam kernel LTS yang sama (misalnya, android11-5.4 ).
    • Stabilitas tidak ada KMI dipertahankan untuk android-mainline .
  • Hanya khusus dentang toolchain disediakan di AOSP dan ditetapkan untuk yang sesuai cabang digunakan untuk membangun kernel dan modul.
  • Hanya simbol yang diketahui digunakan oleh modul sebagaimana ditentukan dalam daftar simbol yang dipantau stabilitasnya dan dianggap sebagai simbol KMI.
    • Konsekuensinya adalah bahwa modul harus hanya menggunakan simbol KMI. Ini diberlakukan dengan gagal memuat modul jika simbol non-KMI diperlukan.
  • Setelah cabang KMI dibekukan, tidak ada perubahan yang dapat merusak KMI, antara lain:
    • Perubahan konfigurasi
    • Perubahan kode kernel
    • Perubahan rantai alat (termasuk pembaruan)

pemantauan KMI

ABI alat monitoring memantau stabilitas KMI selama pengujian presubmit. Perubahan yang merusak KMI gagal mengirimkan pengujian sebelumnya 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 tambalan yang menyinggung atau dengan memfaktorkan ulang tambalan agar kompatibel.

KMI dianggap rusak jika simbol KMI yang ada dimodifikasi dengan cara yang tidak kompatibel. Contoh:

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

Menambahkan simbol baru tidak serta merta merusak KMI, tetapi simbol baru yang digunakan harus ditambahkan ke daftar simbol dan representasi ABI. Jika tidak, perubahan di masa mendatang 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 mereka kompatibel.

Terbaru android11-5.4 biner GKI kernel dapat didownload dari ci.android.com ( kernel_aarch64 membangun).

Kompiler tunggal

Perubahan kompiler dapat mengubah tata letak struktur data kernel internal yang memengaruhi ABI. Karena sangat penting untuk menjaga kestabilan KMI, rantai alat yang digunakan untuk membangun kernel GKI harus sepenuhnya kompatibel dengan rantai alat yang digunakan untuk membuat modul vendor. Kernel GKI dibangun dengan toolchain LLVM yang disertakan 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.

The Android kernel membangun dokumentasi menggambarkan bagaimana kernel referensi GKI dibangun. Secara khusus, prosedur terdokumentasi memastikan bahwa rantai alat dan konfigurasi yang benar digunakan untuk membangun kernel. Mitra hilir didorong untuk menggunakan alat yang sama untuk memproduksi kernel akhir untuk menghindari inkompatibilitas yang disebabkan oleh rantai alat atau dependensi waktu pembangunan 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 pengaruh pada KMI.

Kernel GKI harus dikonfigurasi untuk berjalan di berbagai perangkat. Oleh karena itu, ia 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 untuk kernel dev.

Perubahan boot

Untuk memudahkan pemisahan bersih antara GKI dan penjual komponen, boot partisi hanya berisi komponen generik, termasuk kernel dan ramdisk dengan modul GKI. Versi baru dari boot header (v3) ditentukan untuk menunjukkan kepatuhan terhadap arsitektur GKI. Versi GKI dari boot image dikirimkan oleh Google dan menggantikan versi vendor dari boot image saat menguji kompatibilitas GKI.

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

Ringkasan perubahan disediakan di sini. Lihat vendor partisi boot untuk rincian.

Partisi boot

The boot partisi termasuk header, kernel, dan cpio arsip dari bagian generik 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, itu harus disimpan di partisinya sendiri.
  • DTB: The DTB disimpan di partisi Penjual booting .

The boot partisi berisi arsip cpio dengan komponen GKI:

  • Modul kernel GKI terletak di /lib/modules/
  • first_stage_init dan perpustakaan itu tergantung pada
  • fastbootd dan recovery (digunakan dalam A / B dan Virtual A / perangkat B)

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

Terbaru arm64 android11-5.4 boot.img didownload dari ci.android.com di aosp_arm64 membangun artefak dari aosp-master cabang.

Terbaru arm64 android11-5.4 kernel image ( Image.gz ) dapat didownload dari ci.android.com di kernel_aarch64 membangun artefak dari aosp_kernel-common-android11-5.4 cabang.

Partisi boot vendor

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

Arsip CPIO berisi:

  • Tahap pertama init penjual kernel modul yang terletak di /lib/modules/
  • modprobe config files terletak di /lib/modules
  • modules.load berkas menunjukkan modul untuk beban selama tahap pertama init

Persyaratan bootloader

Bootloader harus memuat generik gambar ramdisk cpio (dari boot partisi ) ke dalam memori segera setelah cpio gambar penjual ramdisk (dari vendor_boot partisi ). 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 image boot GKI yang disediakan oleh Google.

Berkontribusi pada kernel GKI

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

  1. Terbaik: Membuat semua perubahan Anda ke hulu Linux. Jika sesuai, backport ke rilis stabil. Patch ini digabungkan secara otomatis di kernel umum AOSP yang sesuai. Jika tambalan sudah ada di Linux hulu, posting backport tambalan yang sesuai dengan persyaratan tambalan di bawah ini.
  2. Kurang baik: Mengembangkan patch Anda dari pohon (dari sudut pandang Linux hulu pandang). Kecuali patch memperbaiki bug Android-spesifik, mereka sangat tidak mungkin diterima kecuali mereka telah dikoordinasikan dengan kernel-team@android.com .

Untuk mitra yang menerapkan GKI, mungkin ada alasan yang sah mengapa patch out-of-tree diperlukan (terutama jika ada jadwal silikon yang harus dipenuhi). Untuk kasus ini, mengajukan Buganizer masalah.

Mengirimkan perubahan GKI melalui Gerrit ke android-mainline cabang pertama dan kemudian backported untuk cabang rilis lain yang diperlukan.

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 upstream.

Meminta backport dari jalur utama

Umumnya, patch arus utama yang dibutuhkan oleh mitra GKI dapat di-backport ke kernel GKI. Upload patch untuk Gerrit mengikuti pedoman kontribusi .

Jika patch sudah diposting upstream, tetapi belum diterima, disarankan untuk menunggu sampai diterima. Jika jadwal tidak mengizinkan menunggu tambalan diterima di hulu, ajukan masalah Buganizer.

Menambah dan menghapus konfigurasi GKI

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

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

Memodifikasi kode kernel inti

Modifikasi kode kernel inti di kernel umum AOSP tidak disarankan. Pertama-tama kirim tambalan ke Linux hulu dan kemudian 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 kirim tambalan ke hulu yang hanya berisi ekspor simbol. Untuk dipertimbangkan untuk hulu Linux, penambahan EXPORT_SYMBOL_GPL() memerlukan driver modular di-pohon yang menggunakan simbol, sehingga termasuk driver baru atau perubahan pada driver yang ada di patchset sama ekspor.

Saat mengirim tambalan ke hulu, pesan komit harus berisi alasan yang jelas mengapa tambalan diperlukan dan bermanfaat bagi komunitas. Mengaktifkan ekspor untuk mendapatkan manfaat dari driver atau fungsionalitas di luar pohon bukanlah argumen yang meyakinkan bagi pengelola hulu.

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 kemungkinan besar akan diterima sebagai ekspor. Namun, fungsi pembantu internal acak tidak mungkin diterima dan Anda akan diminta untuk memfaktorkan ulang kode Anda agar tidak menggunakannya.

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 sebagai stabil, GKI tidak mengizinkan modul dimuat jika bergantung pada simbol non-KMI.

The extract_symbols Script ekstrak simbol yang relevan dari pohon kernel membangun dan dapat digunakan untuk memperbarui daftar simbol KMI. Mengacu pada dokumentasi simbol daftar untuk rincian lebih lanjut.