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

Pemantauan ABI Kernel Android

Anda dapat menggunakan alat Pemantauan Antarmuka Biner (ABI) aplikasi, tersedia di Android 11 dan lebih tinggi, untuk menstabilkan ABI dalam kernel dari kernel Android. Mengumpulkan perkakas dan membandingkan ABI representasi dari binari kernel yang ada ( vmlinux + modul). ABI representasi adalah .xml file dan daftar simbol. Antarmuka di mana representasi memberikan tampilan disebut Antarmuka Modul Kernel (KMI). Anda dapat menggunakan alat ini untuk melacak dan mengurangi perubahan pada KMI.

ABI pemantauan perkakas yang dikembangkan di AOSP dan menggunakan libabigail untuk menghasilkan dan membandingkan representasi.

Halaman ini menjelaskan perkakas, proses pengumpulan dan analisis representasi ABI, dan penggunaan representasi tersebut untuk memberikan stabilitas pada ABI dalam kernel. Halaman ini juga menyediakan informasi untuk kontribusi perubahan pada kernel Android.

Direktori ini berisi alat khusus untuk analisis ABI. Gunakan dengan membangun script yang disediakan oleh build_abi.sh .)

Proses

Menganalisis ABI kernel membutuhkan beberapa langkah, yang sebagian besar dapat dilakukan secara otomatis:

  1. Memperoleh toolchain, membangun script, dan sumber-sumber kernel melalui repo .
  2. Menyediakan prasyarat (seperti libabigail perpustakaan dan koleksi alat-alat).
  3. Membangun kernel dan representasi ABI nya .
  4. Menganalisis perbedaan ABI antara membangun dan referensi .
  5. Update representasi ABI (jika diperlukan) .
  6. Bekerja dengan daftar simbol .

Petunjuk berikut bekerja untuk kernel yang Anda dapat membangun menggunakan toolchain didukung (seperti prebuilt dentang toolchain). repo manifests tersedia untuk semua cabang kernel umum Android dan selama beberapa kernel khusus perangkat, mereka memastikan bahwa toolchain yang benar digunakan ketika Anda membangun distribusi kernel untuk analisis.

Menggunakan alat Pemantauan ABI

1. Dapatkan rantai alat, skrip build, dan sumber kernel melalui repo

Anda dapat memperoleh toolchain, membangun script (script ini), dan sumber-sumber kernel dengan repo . Untuk dokumentasi rinci, lihat informasi yang sesuai untuk membangun kernel Android .

Untuk menggambarkan proses, langkah-langkah berikut menggunakan common-android12-5.10 , cabang kernel Android, yang merupakan terbaru yang dirilis GKI kernel pada saat tulisan ini. Untuk mendapatkan cabang ini melalui repo , jalankan berikut:

repo init -u https://android.googlesource.com/kernel/manifest -b common-android12-5.10
repo sync

2. Berikan prasyarat

Alat ABI menggunakan libabigail, perpustakaan dan kumpulan alat, untuk menganalisis binari. Satu set cocok binari prebuilt datang dengan kernel-build-alat dan secara otomatis digunakan dengan build_abi.sh .

Untuk memanfaatkan perkakas-tingkat yang lebih rendah (seperti dump_abi ), menambahkan alat kernel-build ke PATH .

3. Bangun kernel dan representasi ABI-nya

Pada titik ini Anda siap untuk membangun sebuah kernel dengan toolchain yang benar dan untuk mengekstrak representasi ABI dari binari nya ( vmlinux + modul).

Mirip dengan yang biasa Android proses kernel build (menggunakan build.sh ), langkah ini membutuhkan berjalan build_abi.sh .

BUILD_CONFIG=common/build.config.gki.aarch64 build/build_abi.sh

Yang membangun kernel dan ekstrak representasi ABI ke out_abi subdirektori. Dalam hal ini out/android12-5.10/dist/abi.xml adalah link simbolik ke out_abi/android12-5.10/dist/abi-<id>.xml . < id> dihitung dengan menjalankan git describe terhadap source kernel.

4. Analisis perbedaan ABI antara build dan representasi referensi

build_abi.sh menganalisa dan melaporkan setiap perbedaan ABI ketika referensi disediakan melalui variabel lingkungan ABI_DEFINITION . ABI_DEFINITION harus menunjuk ke file referensi relatif terhadap source kernel, dan dapat ditentukan pada baris perintah atau, lebih umum, sebagai nilai dalam build.config. Berikut ini memberikan contoh:

BUILD_CONFIG=common/build.config.gki.aarch64 build/build_abi.sh

Dalam perintah di atas, build.config.gki.aarch64 mendefinisikan file referensi (seperti ABI_DEFINITION=android/abi_gki_aarch64.xml ), dan diff_abi panggilan abidiff untuk membandingkan ABI representasi baru yang dihasilkan terhadap file referensi. build_abi.sh mencetak lokasi laporan dan memancarkan laporan singkat untuk setiap kerusakan ABI. Jika pecah terdeteksi, build_abi.sh Menghentikan dan mengembalikan kode nol keluar.

5. Perbarui representasi ABI (jika diperlukan)

Untuk memperbarui representasi ABI, Invoke build_abi.sh dengan --update bendera. Itu update sesuai abi.xml file yang didefinisikan oleh build.config . Untuk mencetak perbedaan ABI karena update, memohon naskah dengan --print-report . Pastikan untuk menyertakan laporan dalam pesan commit ketika memperbarui abi.xml berkas.

6. Bekerja dengan daftar simbol

Parameterisasi build_abi.sh dengan KMI daftar simbol untuk simbol penyaring selama ekstraksi ABI. Ini adalah file teks biasa yang mencantumkan simbol kernel ABI yang relevan. Misalnya, daftar simbol file dengan konten berikut membatasi analisis ABI ke simbol ELF dengan nama symbol1 dan symbol2 :

[abi_symbol_list]
   symbol1
   symbol2

Perubahan pada simbol ELF lainnya tidak dipertimbangkan. Sebuah file daftar simbol dapat ditentukan dalam yang sesuai build.config file konfigurasi dengan KMI_SYMBOL_LIST= sebagai file relatif ke direktori kernel ( $KERNEL_DIR ). Untuk memberikan tingkat organisasi, Anda dapat menentukan tambahan file daftar simbol dengan menggunakan ADDITIONAL_KMI_SYMBOL_LISTS= di build.config berkas. Ini menentukan lebih lanjut file daftar simbol, relatif terhadap $KERNEL_DIR ; pisahkan beberapa nama file dengan spasi.

Untuk membuat daftar simbol awal atau untuk memperbarui yang sudah ada, Anda harus menggunakan build_abi.sh naskah dengan --update-symbol-list parameter.

Ketika script dijalankan dengan konfigurasi yang sesuai, itu membangun kernel dan ekstrak simbol-simbol yang diekspor dari vmlinux dan GKI modul dan yang dibutuhkan oleh modul lain di pohon.

Pertimbangkan vmlinux mengekspor simbol berikut (biasanya dilakukan melalui EXPORT_SYMBOL* macro):

  func1
  func2
  func3

Juga, bayangkan ada dua modul penjual, modA.ko dan modB.ko , yang membutuhkan simbol-simbol berikut (dengan kata lain, mereka daftar undefined entri simbol dalam tabel simbol mereka):

 modA.ko:    func1 func2
 modB.ko:    func2

Dari sudut pandang stabilitas ABI pandang, func1 dan func2 harus tetap stabil, karena mereka digunakan oleh modul eksternal. Sebaliknya, sementara func3 diekspor, tidak aktif digunakan (dengan kata lain, itu tidak wajib) oleh setiap modul. Dengan demikian, daftar simbol mengandung func1 dan func2 saja.

Untuk membuat atau memperbarui daftar simbol yang ada, build_abi.sh harus dijalankan sebagai berikut:

BUILD_CONFIG=path/to/build.config.device build/build_abi.sh --update-symbol-list

Dalam contoh ini, build.config.device harus menyertakan beberapa pilihan konfigurasi:

  • vmlinux harus dalam FILES daftar.
  • KMI_SYMBOL_LIST harus set dan menunjuk pada daftar simbol KMI update.
  • GKI_MODULES_LIST harus diatur dan menunjuk pada daftar modul GKI. Jalur ini biasanya android/gki_aarch64_modules .

Bekerja dengan alat ABI tingkat lebih rendah

Sebagian besar pengguna hanya perlu menggunakan build_abi.sh . Dalam beberapa kasus, bekerja secara langsung dengan perangkat ABI tingkat rendah mungkin diperlukan. Dua perintah yang digunakan oleh build_abi.sh , dump_abi dan diff_abi , tersedia untuk mengekstrak dan membandingkan file ABI. Lihat bagian berikut untuk penggunaannya.

Membuat representasi ABI dari pohon kernel

Disediakan pohon kernel linux dengan built vmlinux dan kernel modul, alat dump_abi menciptakan representasi ABI menggunakan alat ABI yang dipilih. Contoh permintaan terlihat seperti ini:

dump_abi --linux-tree path/to/out --out-file /path/to/abi.xml

File abi.xml berisi ABI representasi tekstual dari gabungan, diamati ABI yang dari vmlinux dan modul kernel di direktori yang diberikan. File ini dapat digunakan untuk inspeksi manual, analisis lebih lanjut, atau sebagai file referensi untuk menegakkan stabilitas ABI.

Membandingkan representasi ABI

Representasi ABI diciptakan oleh dump_abi dapat dibandingkan dengan diff_abi . Gunakan abi-alat yang sama untuk kedua dump_abi dan diff_abi . Contoh permintaan terlihat seperti ini:

diff_abi --baseline abi1.xml --new abi2.xml --report report.out

Daftar laporan yang dihasilkan mendeteksi perubahan ABI yang memengaruhi KMI. File ditetapkan sebagai baseline dan new adalah representasi ABI yang dikumpulkan dengan dump_abi . diff_abi merambat kode keluar dari alat yang mendasari dan karena itu mengembalikan non-nol nilai ketika ABI dibandingkan tidak kompatibel.

Menggunakan daftar simbol KMI

Untuk representasi Filter dibuat dengan dump_abi simbol atau penyaring dibandingkan dengan diff_abi , menggunakan parameter --kmi-symbol-list , yang mengambil jalan ke KMI daftar simbol berkas:

dump_abi --linux-tree path/to/out --out-file /path/to/abi.xml --kmi-symbol-list /path/to/symbol_list_file

Membandingkan binari kernel dengan referensi GKI KMI

Saat Anda sedang bekerja pada kepatuhan GKI Kernel, ini berguna untuk secara teratur membandingkan membangun kernel lokal untuk referensi GKI KMI representasi tanpa harus menggunakan build_abi.sh . Alat gki_check adalah alat ringan untuk melakukan hal itu. Diberikan pohon build Kernel Linux lokal, contoh permintaan untuk membandingkan representasi binari lokal, misalnya, ini adalah cara membandingkan dengan representasi 5.4:

build/abi/gki_check --linux-tree path/to/out/ --kernel-version 5.4

gki_check menggunakan nama parameter konsisten dengan dump_abi dan diff_abi . Oleh karena itu, --kmi-symbol-list path/to/kmi_symbol_list_file dapat digunakan untuk membatasi bahwa dibandingkan dengan simbol-simbol diperbolehkan dengan melewati daftar simbol KMI.

Menangani kerusakan ABI

Sebagai contoh, patch berikut memperkenalkan kerusakan ABI yang sangat jelas:

 diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
  index 5ed8f6292a53..f2ecb34c7645 100644
  --- a/include/linux/mm_types.h
  +++ b/include/linux/mm_types.h
  @@ -339,6 +339,7 @@ struct core_state {
   struct kioctx_table;
   struct mm_struct {
      struct {
  +       int dummy;
          struct vm_area_struct *mmap;            /* list of VMAs */
          struct rb_root mm_rb;
          u64 vmacache_seqnum;                   /* per-thread vmacache */

Ketika Anda menjalankan build_abi.sh lagi dengan patch ini diterapkan, pintu keluar perkakas dengan non-nol kode kesalahan dan melaporkan perbedaan ABI seperti ini:

 Leaf changes summary: 1 artifact changed
  Changed leaf types summary: 1 leaf type changed
  Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
  Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable

  'struct mm_struct at mm_types.h:372:1' changed:
    type size changed from 6848 to 6912 (in bits)
    there are data member changes:
  [...]

Memperbaiki ABI yang rusak di Android Gerrit

Jika Anda tidak dengan sengaja merusak kernel ABI, maka Anda perlu menyelidikinya, menggunakan panduan yang disediakan oleh alat pemantauan ABI. Penyebab kerusakan yang paling umum adalah fungsi yang ditambahkan atau dihapus, struktur data yang diubah, atau perubahan pada ABI yang disebabkan oleh penambahan opsi konfigurasi yang mengarah ke salah satu dari yang disebutkan di atas. Mulailah dengan mengatasi masalah yang ditemukan oleh alat.

Anda dapat mereproduksi tes ABI lokal dengan menjalankan perintah berikut dengan argumen yang sama yang Anda akan menggunakan untuk menjalankan build/build.sh :

Ini adalah contoh perintah untuk kernel GKI:

BUILD_CONFIG=common/build.config.gki.aarch64 build/build_abi.sh

Memperbarui ABI Kernel

Jika Anda perlu memperbarui kernel ABI representasi, maka Anda harus memperbarui yang sesuai abi.xml file dalam source kernel. Yang paling cara mudah untuk melakukan ini adalah dengan menggunakan build/build_abi.sh seperti:

build/build_abi.sh --update --print-report

Gunakan argumen yang sama yang Anda akan digunakan untuk menjalankan build/build.sh . Ini update yang benar abi.xml di pohon sumber dan cetak perbedaan terdeteksi. Sebagai praktik, sertakan laporan tercetak (pendek) dalam pesan komit (setidaknya sebagian).

Cabang Kernel Android dengan ABI yang telah ditentukan sebelumnya

Beberapa cabang kernel hadir dengan representasi ABI yang telah ditentukan sebelumnya untuk Android sebagai bagian dari distribusi sumbernya. ABI representasi dimaksudkan untuk menjadi akurat, dan untuk mencerminkan hasil build_abi.sh seolah-olah Anda akan mengeksekusi pada Anda sendiri. Sebagai ABI sangat dipengaruhi oleh berbagai pilihan konfigurasi kernel, rute .xml file biasanya milik konfigurasi tertentu. Sebagai contoh, common-android12-5.10 cabang berisi abi_gki_aarch64.xml yang bersesuaian dengan hasil membangun ketika menggunakan build.config.gki.aarch64 . Secara khusus, build.config.gki.aarch64 juga mengacu pada file ini melalui ABI_DEFINITION .

Telah ditetapkan representasi ABI tersebut digunakan sebagai definisi dasar ketika membandingkan dengan diff_abi . Misalnya, untuk memvalidasi patch kernel mengenai perubahan pada ABI, membuat representasi ABI dengan patch diterapkan dan menggunakan diff_abi untuk membandingkannya dengan ABI diharapkan untuk pohon sumber tertentu atau konfigurasi. Jika ABI_DEFINITION diatur, berjalan build_abi.sh sesuai akan melakukan.

Menegakkan KMI menggunakan pembuatan versi modul

GKI kernel penggunaan modul versioning ( CONFIG_MODVERSIONS ) untuk menegakkan KMI kepatuhan pada saat runtime. Versi modul akan menyebabkan kegagalan CRC ketidakcocokan di modul beban-waktu jika diharapkan KMI dari modul tidak cocok dengan vmlinux KMI. Sebagai contoh, di sini adalah kegagalan khas yang terjadi pada modul beban-waktu karena ketidakcocokan CRC untuk simbol module_layout() :

init: Loading module /lib/modules/kernel/.../XXX.ko with args ""
XXX: disagrees about version of symbol module_layout
init: Failed to insmod '/lib/modules/kernel/.../XXX.ko' with args ''

Penggunaan versi modul

Pembuatan versi modul berguna karena berbagai alasan:

  1. Ini menangkap perubahan dalam visibilitas struktur data. Jika modul dapat mengubah struktur data buram, seperti struktur data yang bukan bagian dari KMI, modul akan rusak setelah perubahan struktur di masa mendatang.
  2. Ini menambahkan pemeriksaan run-time untuk menghindari secara tidak sengaja memuat modul yang tidak kompatibel dengan KMI dengan kernel. (Seperti ketika modul saat ini dimuat di kemudian hari oleh kernel baru yang tidak kompatibel.) Ini lebih baik daripada memiliki masalah runtime berikutnya yang sulit di-debug atau kernel crash.
  3. abidiff memiliki keterbatasan dalam mengidentifikasi perbedaan ABI dalam kasus-kasus yang berbelit-belit tertentu yang CONFIG_MODVERSIONS dapat menangkap.

Sebagai contoh untuk (1), mempertimbangkan fwnode lapangan di struct device . Bidang yang HARUS buram untuk modul sehingga mereka tidak dapat membuat perubahan pada bidang device->fw_node atau asumsi make tentang ukurannya.

Namun, jika modul meliputi <linux/fwnode.h> (langsung atau tidak langsung), maka fwnode lapangan di struct device berhenti menjadi buram untuk itu. Modul kemudian dapat membuat perubahan device->fwnode->dev atau device->fwnode->ops . Itu bermasalah karena beberapa alasan:

  1. Itu dapat mematahkan asumsi yang dibuat oleh kode kernel inti tentang struktur data internalnya.

  2. Jika pembaruan kernel masa perubahan struct fwnode_handle (tipe data fwnode ), maka modul tidak akan bekerja dengan kernel baru. Selain itu, abidiff tidak akan menunjukkan perbedaan karena modul ini melanggar KMI dengan langsung memanipulasi struktur data internal dengan cara yang tidak dapat ditangkap oleh hanya memeriksa representasi biner.

Mengaktifkan pembuatan versi modul mencegah semua masalah ini.

Memeriksa ketidakcocokan CRC tanpa mem-boot perangkat

Setiap membangun kernel dengan CONFIG_MODVERSIONS diaktifkan tidak menghasilkan Module.symvers berkas sebagai bagian dari proses membangun. File memiliki satu baris untuk setiap simbol diekspor oleh vmlinux dan modul. Setiap baris terdiri dari nilai CRC, nama simbol, simbol namespace, vmlinux atau nama modul yang mengekspor simbol, dan jenis ekspor (misalnya, EXPORT_SYMBOL vs EXPORT_SYMBOL_GPL ).

Anda dapat membandingkan Module.symvers file antara membangun GKI dan membangun Anda untuk memeriksa setiap perbedaan CRC dalam simbol-simbol diekspor oleh vmlinux . Jika ada perbedaan nilai CRC dalam setiap simbol diekspor oleh vmlinux DAN itu digunakan oleh salah satu modul yang Anda muat di perangkat Anda, modul tidak akan dimuat.

Jika Anda tidak memiliki semua membangun artefak, tetapi hanya memiliki vmlinux file dari GKI kernel dan kernel Anda, Anda dapat membandingkan nilai CRC untuk simbol tertentu dengan menjalankan perintah berikut pada kedua kernel, kemudian membandingkan output:

nm <path to vmlinux>/vmlinux | grep __crc_<symbol name>

Sebagai contoh, untuk memeriksa nilai CRC untuk module_layout simbol,

nm vmlinux | grep __crc_module_layout
0000000008663742 A __crc_module_layout

Memperbaiki ketidakcocokan CRC

Jika Anda mendapatkan ketidakcocokan CRC saat memuat modul, berikut cara memperbaikinya:

  1. Membangun GKI kernel dan perangkat kernel Anda, dan tambahkan KBUILD_SYMTYPES=1 di depan perintah yang anda gunakan untuk membangun kernel. Catatan, bila menggunakan build_abi.sh, ini secara implisit diatur sudah. Ini akan menghasilkan .symtypes file untuk setiap .o berkas. Sebagai contoh:

    KBUILD_SYMTYPES=1 BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
    
  2. Menemukan .c file di mana simbol dengan CRC ketidakcocokan diekspor. Sebagai contoh:

    cd common && git grep EXPORT_SYMBOL.*module_layout
    kernel/module.c:EXPORT_SYMBOL(module_layout);
    
  3. Yang .c file memiliki yang sesuai .symtypes file dalam GKI, dan perangkat kernel membangun artefak.

    cd out/$BRANCH/common && ls -1 kernel/module.*
    kernel/module.o
    kernel/module.o.symversions
    kernel/module.symtypes
    

    A. Format file ini adalah satu (berpotensi sangat panjang) baris per simbol.

    B. [s|u|e|etc]# pada awal baris berarti simbol adalah jenis data [struct|union|enum|etc] . Misalnya, t#bool typedef _Bool bool .

    C. Sebuah hilang # awalan di awal baris menunjukkan simbol adalah fungsi. Sebagai contoh,
    find_module s#module * find_module ( const char * ) .

  4. Bandingkan kedua file tersebut dan perbaiki semua perbedaannya.

Kasus 1: Perbedaan karena visibilitas tipe data

Jika salah satu kernel menyimpan simbol atau tipe data buram pada modul-modul dan kernel lain tidak, maka itu muncul sebagai perbedaan antara .symtypes file dari dua kernel. The .symtypes file dari salah satu kernel memiliki UNKNOWN untuk simbol dan .symtypes file dari kernel lain memiliki pandangan diperluas simbol atau data jenis.

Sebagai contoh, asumsikan Anda menambahkan baris ini untuk include/linux/device.h di kernel:

 #include <linux/fwnode.h>

Yang menyebabkan CRC ketidaksesuaian, dengan salah satu dari mereka untuk module_layout() . Jika Anda membandingkan module.symtypes untuk simbol itu, terlihat seperti ini:

 $ diff -u <GKI>/kernel/module.symtypes <your kernel>/kernel/module.symtypes
  --- <GKI>/kernel/module.symtypes
  +++ <your kernel>/kernel/module.symtypes
  @@ -334,12 +334,15 @@
  ...
  -s#fwnode_handle struct fwnode_handle { UNKNOWN }
  +s#fwnode_reference_args struct fwnode_reference_args { s#fwnode_handle * fwnode ; unsigned int nargs ; t#u64 args [ 8 ] ; }
  ...

Jika kernel Anda memiliki sebagai UNKNOWN dan kernel GKI memiliki diperluas pandangan simbol (sangat tidak mungkin), kemudian menggabungkan Android terbaru Umum Kernel ke kernel Anda sehingga Anda menggunakan basis GKI kernel terbaru.

Hampir selalu, GKI kernel memiliki sebagai UNKNOWN , tetapi kernel Anda memiliki rincian internal simbol karena perubahan dibuat untuk kernel Anda. Hal ini karena salah satu file di kernel menambahkan #include yang tidak hadir dalam kernel GKI.

Untuk mengidentifikasi #include yang menyebabkan perbedaan, ikuti langkah berikut:

  1. Buka file header yang mendefinisikan simbol atau tipe data yang memiliki perbedaan ini. Misalnya, mengedit include/linux/fwnode.h untuk struct fwnode_handle .
  2. Tambahkan kode berikut di bagian atas file header:

    #ifdef CRC_CATCH
    #error "Included from here"
    #endif
    
  3. Kemudian dalam modul ini .c berkas (salah satu yang memiliki ketidakcocokan CRC), tambahkan berikut sebagai baris pertama sebelum salah satu #include baris.

    #define CRC_CATCH 1
    
  4. Sekarang kompilasi modul Anda. Anda akan mendapatkan error build-waktu yang menunjukkan rantai file header #include yang menyebabkan ketidaksesuaian CRC ini. Sebagai contoh:

    In file included from .../drivers/clk/XXX.c:16:`
    In file included from .../include/linux/of_device.h:5:
    In file included from .../include/linux/cpu.h:17:
    In file included from .../include/linux/node.h:18:
    .../include/linux/device.h:16:2: error: "Included from here"
    #error "Included from here"
    
  5. Salah satu link di rantai #include adalah karena perubahan dilakukan dalam kernel Anda, yang hilang di kernel GKI.

  6. Setelah Anda mengidentifikasi perubahan, kembali dalam kernel atau meng-upload ke ACK dan mendapatkannya bergabung .

Kasus 2: Perbedaan karena perubahan tipe data

Jika ketidakcocokan CRC untuk simbol atau tipe data bukan karena perbedaan visibilitas, maka itu karena perubahan aktual (penambahan, penghapusan, atau perubahan) pada tipe data itu sendiri. Biasanya, abidiff tangkapan ini, tetapi jika itu meleset karena untuk kesenjangan deteksi diketahui, MODVERSIONS mekanisme dapat menangkap mereka.

Misalnya, anggap Anda membuat perubahan berikut di kernel Anda:

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
  --- a/include/linux/iommu.h
  +++ b/include/linux/iommu.h
  @@ -259,7 +259,7 @@ struct iommu_ops {
     void (*iotlb_sync)(struct iommu_domain *domain);
     phys_addr_t (*iova_to_phys)(struct iommu_domain *domain, dma_addr_t iova);
     phys_addr_t (*iova_to_phys_hard)(struct iommu_domain *domain,
  -        dma_addr_t iova);
  +        dma_addr_t iova, unsigned long trans_flag);
     int (*add_device)(struct device *dev);
     void (*remove_device)(struct device *dev);
     struct iommu_group *(*device_group)(struct device *dev);

Yang akan menyebabkan banyak ketidaksesuaian CRC (karena banyak simbol yang secara tidak langsung dipengaruhi oleh jenis perubahan) dan salah satu dari mereka akan untuk devm_of_platform_populate() .

Jika Anda membandingkan .symtypes file untuk simbol itu, mungkin terlihat seperti ini:

 $ diff -u <GKI>/drivers/of/platform.symtypes <your kernel>/drivers/of/platform.symtypes
  --- <GKI>/drivers/of/platform.symtypes
  +++ <your kernel>/drivers/of/platform.symtypes
  @@ -399,7 +399,7 @@
  ...
  -s#iommu_ops struct iommu_ops { ... ; t#phy
  s_addr_t ( * iova_to_phys_hard ) ( s#iommu_domain * , t#dma_addr_t ) ; int
    ( * add_device ) ( s#device * ) ; ...
  +s#iommu_ops struct iommu_ops { ... ; t#phy
  s_addr_t ( * iova_to_phys_hard ) ( s#iommu_domain * , t#dma_addr_t , unsigned long ) ; int ( * add_device ) ( s#device * ) ; ...

Untuk mengidentifikasi jenis yang diubah, ikuti langkah-langkah berikut:

  1. Menemukan definisi dari simbol dalam kode sumber (biasanya dalam .h file).
  2. Jika ada perbedaan simbol yang jelas antara kernel dan kernel GKI, melakukan git blame untuk menemukan komit.
  3. Terkadang simbol dihapus di satu pohon, dan Anda ingin menghapusnya di pohon lain. Untuk menemukan perubahan yang menghapus baris, jalankan perintah ini di pohon tempat baris dihapus:

    A. git log -S "copy paste of deleted line/word" -- <file where it was deleted>

    B. Anda akan mendapatkan daftar komit yang dipersingkat. Yang pertama mungkin yang Anda cari. Jika tidak, buka daftar sampai Anda menemukan komit.

  4. Setelah Anda mengidentifikasi perubahan, baik kembali dalam kernel atau meng-upload ke ACK dan mendapatkannya bergabung .