Android çekirdeği ABI izlemesi

Şurada bulunan uygulama ikilisi arayüzü (ABI) izleme araçlarını kullanabilirsiniz: Çekirdeği stabilize etmek için Android 11 ve sonraki sürümler Android çekirdeklerinin ABI'si. Araç, ABI temsillerini toplayıp karşılaştırır mevcut çekirdek ikili programlarından (vmlinux+ GKI modülü). Bu ABI .stg dosyaları ve simge listeleridir. İlgili arayüzdeki Bu gösterime Çekirdek Modülü Arayüzü adı verilir. (KMI). Bu araçları, KMI'deki değişiklikleri izlemek ve azaltmak için kullanabilirsiniz.

ABI izleme araçları AOSP'de geliştirilmiştir ve STG (veya libabigail inç Android 13 ve önceki sürümler) oluşturmak ve karşılaştırmak için temsil eder.

Bu sayfada araçlar, ABI toplama ve analiz etme süreci açıklanmaktadır ve bu tür gösterimlerin istikrarlı bir şekilde ABI'yi kullanabilirsiniz. Bu sayfada, katkıda bulunulan değişikliklere ilişkin bilgiler de yer almaktadır geri dönelim.

Süreç

Çekirdek ABI'sinin analizi birkaç adımdan oluşur. Bunların çoğu otomatik hale getirilebilir:

  1. Çekirdek ve ABI temsilini oluşturun.
  2. Derleme ve referans arasındaki ABI farklılıklarını analiz edin.
  3. ABI temsilini güncelleyin (gerekirse).
  4. Sembol listeleriyle çalışın.

Aşağıdaki talimatlar, oluşturabileceğiniz çekirdek desteklenen araç zinciri (önceden oluşturulmuş Clang araç zinciri gibi) sağlar. repo manifests Android'in tüm ortak çekirdek dallarında ve oluşturulduğundan emin olmak için, cihaza özgü çekirdekleri derleyerek göstermenizi sağlar.

Sembol listeleri

KMI, çekirdekteki tüm simgeleri, hatta 30.000'in üzerinde dışa aktarılan simgeler. Bunun yerine tedarikçi modülleri tarafından kullanılabilecek simgeler kök dizinde herkese açık bir şekilde saklanan bir simge listesi dosyaları grubunda açıkça listelenmektedir. örneğidir. Tüm simge listesi dosyalarındaki tüm simgelerin birleşimi kararlı olarak tutulan KMI sembolleri kümesini tanımlar. Örnek simge listesi dosyası : abi_gki_aarch64_db845c, için gereken simgeleri belirten DragonBoard 845c.

Sadece bir simge listesinde listelenen simgeler ve bunlarla ilişkili yapılar ve tanımlar, KMI kapsamında kabul edilir. Değişiklikleri sembol listesinde görebilirsiniz. Yeni arayüzler kullanıma sunulduktan sonra KMI tanımının parçası olan bir sembol listesinde olup ve simge listesinden çıkarılmamalı veya dal donduruldu.

Her Android Ortak Çekirdeği (ACK) KMI çekirdeği dalının kendi sembol grubu vardır listeler. Farklı KMI çekirdeği arasında ABI kararlılığı sağlamak için herhangi bir girişimde bulunulmaz dalları. Örneğin, android12-5.10 KMI'si şunlardan tamamen bağımsızdır: android13-5.10 için KMI.

ABI araçları, KMI simge listelerini kullanarak hangi arayüzlerin izlenmesi gerektiğini sınırlandırır istikrar sağlar. İlgili içeriği oluşturmak için kullanılan ana simge listesi GKI çekirdek modüllerinin gerektirdiği sembolleri içerir. Satıcılar sağlandığından emin olmak için ek simge listelerinin gönderilmesi ve güncellenmesi ABI ile uyumluluk sağlamak için kullandıkları arayüzler. Örneğin, Yeşil Ofis’teki android13-5.15 için sembol listeleri hakkında daha fazla bilgi edinmek için https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.15/android

Bir simge listesi, belirli bir öğe için gerekli olduğu bildirilen simgeleri veya cihaza bağlı olarak değişebilir. Araçların kullandığı tam liste, tüm bu araçların KMI simge listesi dosyaları. ABI araçları, her sembolün ayrıntılarını belirler. işlev imzası ve iç içe yerleştirilmiş veri yapılarını tanıtır.

KMI dondurulduğunda mevcut KMI arayüzlerinde hiçbir değişiklik yapılmasına izin verilmez; sabittirler. Ancak tedarikçiler KMI'ye istedikleri zaman sembol ekleyebilirler devam ettirebilirsiniz. Yeni eklenenler sembolleri bir KMI simge listesinde belirtildiği anda sabit kalır. Çekirdek teyit edilemediği sürece listeden semboller kaldırılmamalıdır hiçbir cihazın bu sembole bağımlı bir şekilde gönderilmediği anlamına gelir.

Şu adresteki talimatları uygulayarak bir cihaz için KMI simge listesi oluşturabilirsiniz: Simge listeleriyle çalışma. Birçok iş ortağı, ACK başına bir sembol listesi gönderir ancak bu zorunlu bir gereklilik değildir. Bakıma yardımcı olacaksa birden fazla sembol listesi gönderebilirsiniz.

KMI'yi genişletme

KMI sembolleri ve ilgili yapılar kararlı (yani KMI'si donmuş olan bir çekirdekteki kararlı arayüzleri bozan değişiklikler kabul edilir) GKI çekirdeği uzantılara açık kalır. Böylece, takip eden KMI’nin planlandığı gibi gitmeden önce tüm bağımlılıklarını tanımlaması donduruldu. KMI'nin kapsamını genişletmek için KMI'ye yeni veya KMI donmuş olsa bile dışa aktarılan mevcut çekirdek işlevlerinin yerine getirilmesini sağlar. Yeni çekirdek yamalar, KMI'yı ihlal etmedikleri takdirde de kabul edilebilir.

KMI kesintileri hakkında

Çekirdeklerde kaynaklar bulunur ve ikili programlar bu kaynaklardan oluşturulur. ABI tarafından izlenen çekirdek dalları, geçerli GKI'nın ABI temsilini içerir ABI (.stg dosyası biçiminde). İkili programlardan sonra (vmlinux, Image ve herhangi bir GKI modülü) oluşturulmuşsa dosyadan ABI temsili her zaman daha iyidir. Çekirdek kaynak dosyasında yapılan herhangi bir değişiklik, ikili programları ve çevirmesi, ayıklanan .stg öğelerini de etkiler. AbiAnalyzer analizcisi, derleme yapılarından çıkarılan .stg dosyasını kullanır ve Anlamsal bir farklılık bulursa Gerrit'teki değişiklik hakkında Lint-1 etiketi.

ABI kesintilerini yönetme

Örneğin, aşağıdaki yama oldukça bariz bir ABI kesintisini ortaya çıkarmıştır:

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 42786e6364ef..e15f1d0f137b 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -657,6 +657,7 @@ struct mm_struct {
                ANDROID_KABI_RESERVE(1);
        } __randomize_layout;

+       int tickle_count;
        /*
         * The mm_cpumask needs to be at the end of mm_struct, because it
         * is dynamically sized based on nr_cpu_ids.

Bu yama uygulanmış olarak derleme ABI'yı çalıştırdığınızda araç, bir hata kodu gösterir ve şuna benzer bir ABI farkı bildirir:

function symbol 'struct block_device* I_BDEV(struct inode*)' changed
  CRC changed from 0x8d400dbd to 0xabfc92ad

function symbol 'void* PDE_DATA(const struct inode*)' changed
  CRC changed from 0xc3c38b5c to 0x7ad96c0d

function symbol 'void __ClearPageMovable(struct page*)' changed
  CRC changed from 0xf489e5e8 to 0x92bd005e

... 4492 omitted; 4495 symbols have only CRC changes

type 'struct mm_struct' changed
  byte size changed from 992 to 1000
  member 'int tickle_count' was added
  member 'unsigned long cpu_bitmap[0]' changed
    offset changed by 64

Derleme zamanında ABI farklılıkları algılandı

Hataların en yaygın nedeni, sürücünün çekirdeğine sahip bir çekirdeksiniz.

Sembol, sembol listesinde (android/abi_gki_aarch64) yoksa önce dosyanın dışa aktarıldığını ve EXPORT_SYMBOL_GPL(symbol_name) ve ardından ABI XML gösterimi ve simge listesi. Örneğin, aşağıdaki değişiklikler yeni Artımlı FS özelliğini android-12-5.10 dalına Sembol listesinin ve ABI XML temsilinin güncellenmesini içerir.

  • Özellik değişikliği örneği: aosp/1345659 adresinde bulabilirsiniz.
  • Sembol listesi örneği: aosp/1346742 adresinde bulabilirsiniz.
  • ABI XML değişikliği örneği aosp/1349377.

Sembol dışa aktarılmışsa (sizin tarafınızdan veya daha önce dışa aktarılmışsa) ancak kullanıyorsanız aşağıdakine benzer bir derleme hatası alabilirsiniz.

Comparing the KMI and the symbol lists:
+ build/abi/compare_to_symbol_list out/$BRANCH/common/Module.symvers out/$BRANCH/common/abi_symbollist.raw
ERROR: Differences between ksymtab and symbol list detected!
Symbols missing from ksymtab:
Symbols missing from symbol list:
 - simple_strtoull

Sorunu çözmek için hem çekirdeğinizde hem de ACK'de KMI simge listesini güncelleyin (bkz. ABI temsilini güncelleyin). Örneğin, hakkında daha fazla bilgi için aosp/1367601.

Çekirdek ABI kesintilerini çözme

Kodu yeniden düzenleyerek çekirdek ABI kesintilerini giderebilirsiniz. ABI veya ABI temsilini güncelleme. Şunları kullanın: durumunuza en uygun yaklaşımı belirlemek için kullanabilirsiniz.

ABI Döküm Akış Grafiği

Şekil 1. ABI kesinti çözümü

ABI değişikliklerini önlemek için kodu yeniden düzenleyin

Mevcut ABI'da değişiklik yapmamak için elinizden geleni yapın. Birçok durumda ABI'yı etkileyen değişiklikleri kaldırmak için kodunuzu yeniden düzenleyin.

  • Yapı alanı değişikliklerini yeniden düzenleme. Hata ayıklama için ABI'da değişiklik yapıldığında özelliğinde, alanların etrafına bir #ifdef ekleyin (struct ve source referansları) ve #ifdef için kullanılan CONFIG öğesinin üretim defconfig ve gki_defconfig. Hata ayıklama türünün yapılandırma, ABI'yı bozmadan bir struct'a eklenebilir. Bu yamaset'ten yararlanın.

  • Temel çekirdeği değiştirmemek için özellikleri yeniden düzenleme. Yeni özelliklerin Eklenmesi için ABI'yi yeniden düzenlemeye çalışın. bölümünü kullanıma sunduk. Örnek olarak mevcut çekirdek ABI'yi kullanarak, çekirdek ABI'nın aosp/1312213.

Android Gerrit'te bozuk ABI'yı düzeltme

Çekirdek ABI'sini kasıtlı olarak kırmadıysanız bunu araştırmanız, rehberlikten yararlanın. En yaygın kesintilerin nedenleri değiştirilmiş veri yapıları ve ilişkili CRC simgesidir. veya yukarıda belirtilenlerden herhangi birine yol açan yapılandırma seçeneği değişiklikleri nedeniyle. Aracın bulduğu sorunları gidererek başlayın.

ABI bulgularını yerel olarak yeniden oluşturabilirsiniz. Çekirdek ve ABI temsilini oluşturun.

Lint-1 etiketleri hakkında

Dondurulmuş veya kesinleşmiş bir KMI içeren dala değişiklikleri yüklerseniz Değişikliklerin kararlı sürümü etkilememesi için değişiklikler AbiAnalyzer tarafından geçmelidir hale getirmiyor. Bu işlem sırasında AbiAnalyzer, derleme sırasında oluşturulan ABI raporu ( normal derlemeyi ve ardından bazı ABI ayıklama ve karşılaştırma adımlarını içerir.

AbiAnalyzer boş olmayan bir rapor bulursa Lint-1 etiketini ve Sorun çözülene kadar değişiklik gönderilmesinin engellenmesi; yama kümesi gönderilene kadar Lint+1 etiketi.

Çekirdek ABI'sını güncelleme

ABI'da değişiklik yapmak gerekmiyorsa kod değişikliklerinizi uygulamalısınız. ABI temsilini ve sembol listesini ACK'ye aktarmalıdır. Lint'i GKI uyumluluğunu bozmamak için -1'i kaldırın ve aşağıdaki adımları uygulayın:

  1. Kod değişikliklerini ACK'ye yükleyin.

  2. Yama kümesi için bir Kod İncelemesi +2 almayı bekleyin.

  3. Referans ABI temsilini güncelleyin.

  4. Kod değişikliklerinizi ve ABI güncelleme değişikliğini birleştirin.

ziyaret edin.

ABI kodu değişikliklerini ACK'ye yükleme

ACK ABI'nin güncellenmesi, yapılan değişikliğin türüne bağlıdır.

  • Bir ABI değişikliği CTS veya VTS testlerini etkileyen bir özellikle ilgiliyse değişiklik genellikle ACK’ye ilk olarak seçilebilir. Örnek:

  • ABI değişikliği, ACK ile paylaşılabilecek bir özellikle ilgiliyse ACK’ye olması gerektiği gibi seçilebilir. Örneğin, aşağıdaki değişiklikler CTS veya VTS testi için gerekli değildir ancak ACK ile paylaşılabilir:

  • Bir ABI değişikliği, teste dahil edilmesi gerekmeyen yeni bir özellik içeren etiketleri ACK'ye eklemek için ele alacağız.

ACK için saplama kullanın

Saplamalar yalnızca (ör. performans ve güç değişiklikleri gibi) ACK. Aşağıdaki liste ayrıntıları örnekleri .

  • Çekirdek izole özellik saplaması (aosp/1284493). ACK'deki özellikler gerekli değildir ancak sembollerin mevcut olması gerekir bu simgeleri kullanması için ACK'ye bakın.

  • Tedarikçi firma modülü için yer tutucu simgesi (aosp/1288860).

  • Süreç bazında yalnızca ABI tarafından seçilen mm etkinlik izleme özelliği (aosp/1288454). Orijinal yama ACK'ye seçilmiş ve daha sonra yalnızca task_struct ve UA mülkleri arasındaki ABI farkını gidermek için mm_event_count. Bu yama, mm_event_type sıralamasında da güncellemelere dahil ederek son üyelere ulaşabilirsiniz.

  • Yalnızca daha fazlasını gerektiren termal yapı ABI değişikliklerini kısmi olarak seçme yeni ABI alanları ekleyin.

    • Bant aosp/1255544 iş ortağı çekirdeği ve ACK arasındaki ABI farklılıklarını çözüme kavuşturdu.

    • Bant aosp/1291018 , önceki yamanın GKI testi sırasında bulunan işlevsel sorunları düzeltti. Bu düzeltme, tek bir sensörde birden fazla termal bölge içerebilir.

  • CONFIG_NL80211_TESTMODE ABI değişikliği (aosp/1344321). Bu yama, ABI için gerekli struct değişikliklerini ekledi ve ek alanların işlevsel farklılıklara neden olmaması, CONFIG_NL80211_TESTMODE ürününü üretim çekirdeklerine eklemeye devam edecek. GKI uyumluluğunu sağlamak için.

ziyaret edin.

Çalışma zamanında KMI'yı zorunlu kıl

GKI çekirdekleri, dışa aktarılan sembolleri sınırlayan TRIM_UNUSED_KSYMS=y ve UNUSED_KSYMS_WHITELIST=<union of all symbol lists> yapılandırma seçeneklerini kullanır (örneğin, EXPORT_SYMBOL_GPL() kullanılarak dışa aktarılan simgeler) simge listesi. Diğer tüm simgeler dışa aktarılmaz ve bir modül yüklenmesi için dışa aktarılmadı simgesi reddedilir. Bu kısıtlama, derleme zamanında uygulanır ve eksik girişler işaretlenir.

Geliştirme amacıyla sembolün kırpılması (yani genellikle dışa aktarılan tüm simgeler kullanılabilir). Yerini bulmak için bu derlemeleri görmek için kernel_debug_aarch64 ci.android.com adresine gidin.

Modül sürümü oluşturmayı kullanarak KMI'yi zorunlu kılma

Genel Çekirdek Görüntüsü (GKI) çekirdekleri modül sürümü oluşturmayı kullanır (CONFIG_MODVERSIONS) belirler. Modül sürümü oluşturma, döngüsel artıklık denetimi (CRC) uyuşmazlığına neden olabilir bir modülün beklenen KMI'si vmlinux KMI. Örneğin, aşağıdaki örnek normal bir hata olduğunda module_layout() simgesi için CRC uyuşmazlığından dolayı modül yükleme süresi:

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 ''

Modül sürümü oluşturmanın kullanımları

Modül sürümü oluşturma aşağıdaki nedenlerle yararlıdır:

  • Modül sürümü oluşturma, veri yapısı görünürlüğündeki değişiklikleri yakalar. Modüller opak veri yapılarını, yani yapıda gelecekte yapılacak değişikliklerden sonra bozulur.

    fwnode struct device alanındaki değer. Bu alanın, modüllerde değişiklik yapamaması için opak olması ZORUNLUDUR alanını device->fw_node içine alın veya boyutu hakkında varsayımlarda bulunun.

    Ancak bir modül <linux/fwnode.h> içeriyorsa (doğrudan veya dolaylı olarak), struct device içindeki fwnode alanı artık opak olmaz. İlgili içeriği oluşturmak için kullanılan modülün ardından device->fwnode->dev veya device->fwnode->ops. Bu senaryo birkaç nedenden dolayı sorunludur, şu şekilde ifade edilmektedir:

    • Temel çekirdek kodunun kendi dahili veri kodu hakkında yaptığı varsayımları yıkabilir veri yapıları.

    • Gelecekteki bir çekirdek güncellemesinde struct fwnode_handle (veriler fwnode türünü seçerseniz modül artık yeni çekirdekle çalışmaz. Ayrıca, modül bozulduğu için stgdiff herhangi bir farklılık göstermeyecek dahili veri yapılarını mümkün olmayan şekillerde etkileyerek yalnızca ikili gösterim incelenerek yakalanabilir.

  • Mevcut bir modül daha sonraki bir tarihte yüklendiğinde KMI ile uyumsuz olarak kabul edilir yeni bir çekirdek tarafından çalıştırılacaktır. Modül sürümü oluşturma, çekirdekle KMI uyumlu olmayan bir modülü yanlışlıkla yüklemeyin. Bu denetim, hata ayıklaması zor çalışma zamanı sorunlarını ve gerçekleşebilecek çekirdek kilitlenmelerini KMI'de saptanmamış bir uyumsuzluktan kaynaklanmaktadır.

Modül sürümü oluşturmanın etkinleştirilmesi tüm bu sorunların önüne geçer.

Cihazı başlatmadan CRC uyuşmazlıklarını kontrol edin

stgdiff, diğer çekirdeklerle çekirdekler arasındaki CRC uyuşmazlıklarını ABI farklılıkları.

Ayrıca, CONFIG_MODVERSIONS özelliğinin etkin olduğu tam çekirdek derlemesi Module.symvers dosyası olarak yükleyebilirsiniz. Bu dosyada bir satırı.vmlinux Her biri satır; CRC değeri, simge adı, simge ad alanı, vmlinux veya dışa aktaran modül adını ve dışa aktarma türünü (örneğin, EXPORT_SYMBOL - EXPORT_SYMBOL_GPL) karşılaştırması.

GKI derlemesi ile derlemeniz arasında Module.symvers dosyalarını karşılaştırabilirsiniz kontrol etmek için vmlinux tarafından dışa aktarılan simgelerde CRC farklılıkları olup olmadığını kontrol edin. Varsa vmlinux tarafından dışa aktarılan herhangi bir simgedeki CRC değer farkı ve cihazınıza yüklediğiniz modüllerden biri tarafından kullanılıyorsa modül, yükleyin.

Tüm derleme yapılarına sahip değilseniz ancakvmlinux arasında bağlantı kurmak için, GKI çekirdeğinin ve çekirdeğinizin aşağıdaki komutu her iki çekirdekte de çalıştırarak ve çıkış:

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

Örneğin, aşağıdaki komut, module_layout için CRC değerini kontrol eder simge:

nm vmlinux | grep __crc_module_layout
0000000008663742 A __crc_module_layout

CRC uyuşmazlıklarını giderme

Bir modül yüklenirken CRC uyuşmazlığını gidermek için aşağıdaki adımları uygulayın:

  1. --kbuild_symtypes öğesini kullanarak GKI çekirdeğini ve cihaz çekirdeğini oluşturun. seçeneği mevcuttur:

    tools/bazel run --kbuild_symtypes //common:kernel_aarch64_dist

    Bu komut, her .o dosyası için bir .symtypes dosyası oluşturur. Görüntüleyin KBUILD_SYMTYPES Kleaf inceleyebilirsiniz.

    Android 13 ve önceki sürümler için GKI çekirdeğini derleme Ayrıca, cihaz çekirdeğinizde KBUILD_SYMTYPES=1 komutunun başına aşağıdaki komutta gösterildiği gibi, çekirdeği oluşturmak için kullanın:

    KBUILD_SYMTYPES=1 BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh

    build_abi.sh, kullanılırken KBUILD_SYMTYPES=1 işareti örtülü olarak ayarlanır zaten.

  2. CRC uyuşmazlığına sahip simgenin aşağıdakileri kullanarak dışa aktarıldığı .c dosyasını bulun: şu komutu kullanın:

    cd common && git grep EXPORT_SYMBOL.*module_layout
kernel/module.c:EXPORT_SYMBOL(module_layout);

  3. GKI'da .c dosyasının karşılık gelen .symtypes dosyası vardır ve cihaz çekirdeği derleme yapıları. Aşağıdakileri kullanarak .c dosyasını bulun komutları:

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

    .c dosyasının özellikleri şunlardır:

    • .c dosyasının biçimi, simge başına bir (potansiyel olarak çok uzun) satırdır.

    • Satırın başındaki [s|u|e|etc]#, simgenin bir veri türünde olduğu anlamına gelir [struct|union|enum|etc]. Örnek:

      t#bool typedef _Bool bool

    • Satırın başında # önekinin eksik olması, bir fonksiyondur. Örnek:

      find_module s#module * find_module ( const char * )

  4. İki dosyayı karşılaştırın ve tüm farkları düzeltin.

ziyaret edin.

1. Örnek: Veri türünün görünürlüğünden kaynaklanan farklılıklar

Bir çekirdekte bir simge veya veri türü modüllerde, diğeri ise üzerinde opak görünüyorsa çalışmazsa .symtypes dosyaları arasında bu fark vardır. Çekirdeklerden birindeki .symtypes dosyası UNKNOWN değerine sahip ve diğer çekirdekteki .symtypes dosyası genişletilmiş bir görünüme sahip simgesini veya veri türünü seçin.

Örneğin, aşağıdaki satırı Çekirdekinizdeki include/linux/device.h dosyası CRC uyuşmazlıklarına neden olur. Bunlardan biri module_layout() içindir:

 #include <linux/fwnode.h>

Bu simge için module.symtypes karşılaştırıldığında şu değer elde edilir: farklar:

 $ 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 ] ; }
  ...

Çekirdeğiniz UNKNOWN değerine sahipse ve GKI çekirdeği genişletilmiş görünüme sahipse çok düşük bir ihtimal), ardından en son Android Common Kernel'i .

Çoğu durumda, GKI çekirdeği UNKNOWN değerine sahiptir ancak çekirdeğiniz çekirdeğinizde yapılan değişikliklerden dolayı simgenin dahili ayrıntılarıdır. Bu çünkü çekirdekinizdeki dosyalardan biri, #include .

Çoğu zaman düzeltme yeni #include bilgisini genksyms alanında gizlemekten ibarettir.

#ifndef __GENKSYMS__
#include <linux/fwnode.h>
#endif

Aksi takdirde, farka neden olan #include öğesini belirlemek için şu adımları uygulayın: için şu adımları izleyin:

  1. Buna sahip simgeyi veya veri türünü tanımlayan başlık dosyasını açın: farkına varır. Örneğin, şunun için include/linux/fwnode.h öğesini düzenleyin: struct fwnode_handle.

  2. Başlık dosyasının en üstüne aşağıdaki kodu ekleyin:

    #ifdef CRC_CATCH
#error "Included from here"
#endif

  3. Modülün .c dosyasında CRC uyuşmazlığı olan #include satırlarının herhangi birinden önceki ilk satır olarak takip edin.

    #define CRC_CATCH 1

  4. Modülünüzü derleyin. Ortaya çıkan derleme zamanı hatası, başlık dosyası (#include) bu CRC uyuşmazlığına neden olmuştur. Örnek:

    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"

    Bu #include zincirindeki bağlantılardan biri, yoksa GKI çekirdeğinde yoktur.

  5. Değişikliği belirleyin, çekirdekte geri alın veya Hesabı ACK'ye yükleyip birleştirmesini sağlayabilirsiniz.

2. Örnek: Veri türü değişikliklerinden kaynaklanan farklılıklar

Bir simge veya veri türü için CRC uyuşmazlığının nedeninin veya kapsamdaki gerçek değişikliklerden (eklemeler, kaldırmalar veya değişiklikler) veri türünün kendisi.

Örneğin, çekirdeğinizde aşağıdaki değişikliğin yapılması çeşitli CRC'ye neden olur dolaylı olarak etkilenen çok sayıda simge olduğu için uyuşmazlıklar:

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);

devm_of_platform_populate() için bir CRC uyuşmazlığı var.

Bu simgenin .symtypes dosyalarını karşılaştırırsanız simge aşağıdaki gibi görünebilir:

 $ 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 * ) ; ...

Değiştirilen türü belirlemek için aşağıdaki adımları izleyin:

  1. Kaynak kodundaki simgenin tanımını bulun (genellikle .h dosyalarında).

    • Çekirdeğiniz ve GKI çekirdeği arasındaki sembol farklılıkları için kaydı bulmak için şu komutu çalıştırın:
    git blame
    • Silinen simgeler için (ağaçtaki bir simgenin silindiği ve diğer ağaçta silmek istiyorsanız), bunu yaptığınızda satırı sildi. Ağaçta, aşağıdaki komutu kullanarak silindi:
    ziyaret edin. 
    git log -S "copy paste of deleted line/word" -- <file where it was deleted>

  2. Değişikliği veya silme işlemini bulmak için döndürülen kaydetme listesini inceleyin. İlgili içeriği oluşturmak için kullanılan ilk kayıt muhtemelen aradığınız kayıttır. Uygun değilse kaydı bulana kadar bekleyin.

  3. Değişikliği belirledikten sonra, çekirdekte değişikliği geri alın veya ACK'ye yükleyip alın birleştirildi.