אתם יכולים להשתמש בכלים למעקב אחרי ממשק בינארי של אפליקציה (ABI), שזמינים ב-Android 11 ואילך, כדי לייצב את ה-ABI בתוך הליבה של ליבות Android. הכלי אוסף ומשויך בין ייצוגים של ABI מקובצי בינארי קיימים של הליבה (vmlinux + מודולים של GKI). הייצוגים האלה של ABI הם קובצי .stg ורשימות הסמלים. הממשק שבו הייצוג מספק תצוגה נקרא Kernel Module Interface (KMI). אפשר להשתמש בכלים כדי לעקוב אחרי השינויים ב-KMI ולצמצם אותם.
הכלים למעקב אחרי ABI פותחו ב-AOSP ומשתמשים ב-STG (או ב-libabigail ב-Android 13 ומטה) כדי ליצור ייצוגים ולהשוות ביניהם.
בדף הזה מתוארים הכלים, תהליך האיסוף והניתוח של ייצוגי ABI והשימוש בייצוגים כאלה כדי לספק יציבות ל-ABI בליבה. בדף הזה מופיע גם מידע על שליחת שינויים לליבת Android.
תהליך
ניתוח ה-ABI של הליבה כולל כמה שלבים, שרובם אפשר לבצע באופן אוטומטי:
- יצירת הליבה והייצוג שלה ב-ABI.
- ניתוח ההבדלים ב-ABI בין ה-build לבין קובץ עזר.
- עדכון הייצוג של ABI (אם יש צורך).
- עבודה עם רשימות סמלים
ההוראות הבאות מתאימות לכל ליבה שאפשר ליצור באמצעות מערכת כלים נתמכת (כמו צרור הכלים של Clang) המובנה מראש. repo manifestsזמינים לכל ההסתעפויות הנפוצות של הליבה של Android ולכמה ליבות ספציפיות למכשיר. הם מבטיחים שייעשה שימוש בכלי העבודה הנכון כשמפתחים הפצה של ליבה לצורך ניתוח.
רשימות סמלים
KMI לא כולל את כל הסמלים בליבה (kernel) או אפילו את כל מעל 30,000 הסמלים שיוצאו. במקום זאת, הסמלים שאפשר להשתמש בהם במודולים של ספקים מפורטים במפורש בקבוצה של קובצי רשימת סמלים שמנוהלים באופן ציבורי ברמה הבסיסית של עץ הליבה. איחוד כל הסמלים בכל הקבצים של רשימת הסמלים מגדיר את קבוצת סמלי ה-KMI שנשמרת כיציבה. קובץ לדוגמה של רשימת סמלים הוא abi_gki_aarch64_db845c, שמצהיר על הסמלים הנדרשים ל-DragonBoard 845c.
רק הסמלים שמפורטים ברשימת סמלים והמבנים וההגדרות המשויכים שלהם נחשבים כחלק מ-KMI. אם הסמלים שאתם צריכים לא מופיעים, תוכלו לפרסם שינויים ברשימות הסמלים. אחרי שממשקים חדשים מופיעים ברשימת סמלים, והם חלק מהתיאור של KMI, הם נשמרים כיציבים ואי אפשר להסיר אותם מרשימת הסמלים או לשנות אותם אחרי שההסתעפות קופאת.
לכל הסתעפות ליבה (KMI) של Android Common KMI יש קבוצה משלה של רשימות סמלים. לא מתבצע ניסיון לספק יציבות ABI בין הסתעפויות שונות של הליבה של KMI. לדוגמה, ה-KMI של android12-5.10 לא תלוי בכלל ב-KMI של android13-5.10.
כלי ABI משתמשים ברשימות סמלים של KMI כדי להגביל את הממשקים שצריך לעקוב אחריהם כדי לוודא שהם יציבים. רשימת הסמלים הראשית מכילה את הסמלים הנדרשים למודול הליבה של GKI. הספקים נדרשים לשלוח ולעדכן רשימות סמלים נוספות כדי להבטיח שהממשקים שהם מסתמכים עליהם ימשיכו להיות תואמים ל-ABI. לדוגמה, כדי לראות רשימה של רשימות סמלים של android13-5.15, ראו https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.15/android
רשימת סמלים מכילה את הסמלים שדווחו כנדרש לספק או למכשיר הספציפי. הרשימה המלאה שבה משתמשים הכלים היא האיחוד של כל קבצי רשימת הסמלים של KMI. כלי ה-ABI קובעים את הפרטים של כל סמל, כולל חתימה של פונקציה ומבנים של נתונים בתצוגת עץ.
בהקפאת ה-KMI, לא ניתן לבצע שינויים בממשקי ה-KMI הקיימים – הם יציבים. עם זאת, ספקים יכולים להוסיף סמלים ל-KMI בכל שלב, כל עוד התוספות לא משפיעות על היציבות של ה-ABI הקיים. סמלים חדשים שנוספו נשמרים ביציבות ברגע שמצוטטים אותם ברשימת סמלי KMI. לא מומלץ להסיר סמלים מרשימת הליבה, אלא אם אפשר לאשר שלעולם לא נשלח מכשיר עם תלות באותו סמל.
אפשר ליצור רשימת סמלים של KMI למכשיר לפי ההוראות במאמר איך עובדים עם רשימות סמלים. שותפים רבים שולחים רשימת סמלים אחת לכל ACK, אבל זו לא דרישת חובה. אם זה עוזר בתחזוקה, אפשר לשלוח כמה רשימות של סמלים.
הרחבת ה-KMI
סמלי KMI ומבנים קשורים נשמרים כיציבים (כלומר, לא ניתן לקבל שינויים שמשביתים ממשקים יציבים בליבה עם KMI קפוא), אבל הליבה של GKI נשארת פתוחה לתוספים, כך שמכשירים שנשלחים מאוחר יותר בשנה לא צריכים להגדיר את כל יחסי התלות שלהם לפני הקפאת ה-KMI. כדי להרחיב את ה-KMI, תוכלו להוסיף ל-KMI סמלים חדשים לפונקציות ליבה (kernel) חדשות או קיימות, גם אם ה-KMI קפוא. יכול להיות שיתקבלו גם תיקוני ליבה חדשים אם הם לא מפרים את ה-KMI.
מידע על שגיאות KMI
לליבת לינוקס יש מקורות, והקובצי הבינארי נוצרים מהמקורות האלה.
ההסתעפויות של הליבה שנמצאות במעקב אחרי ABI כוללות ייצוג ABI של ABI הנוכחי של GKI (בצורת קובץ .stg). אחרי היצירה של הקבצים הבינאריים (vmlinux, Image וכל המודולים של GKI), אפשר לחלץ מהם ייצוג ABI. כל שינוי שמתבצע בקובץ המקור של הליבה יכול להשפיע על הקבצים הבינאריים, ובתגובה גם על .stg שחולץ. המנתח AbiAnalyzer משווה את הקובץ .stg המחויב עם הקובץ שנשלף מפריטי ה-build, ומגדיר תווית Lint-1 לשינוי ב-Gerrit אם הוא מוצא הבדל סמנטי.
טיפול בתקלות ב-ABI
לדוגמה, התיקון הבא גורם לשבירה בולטת מאוד של ABI:
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.
כשמריצים את ה-build ABI עם התיקון הזה, הכלי יוצא עם קוד שגיאה שאינו אפס ומדווח על הבדל ב-ABI, בדומה לדוגמה הבאה:
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
הבדלים ב-ABI שזוהו בזמן ה-build
הסיבה השכיחה ביותר לשגיאות היא כאשר הנהג משתמש בסמל חדש מהליבה שלא נמצא באף אחת מרשימות הסמלים.
אם הסמל לא כלול ברשימת הסמלים (android/abi_gki_aarch64), צריך קודם לוודא שהוא מיוצא עם EXPORT_SYMBOL_GPL(symbol_name) ואז לעדכן את הייצוג ואת רשימת הסמלים של ABI. לדוגמה, השינויים הבאים מוסיפים את התכונה החדשה Incremental FS להסתעפות android-12-5.10, כולל עדכון של רשימת הסמלים ומייצג ה-XML של ABI.
- דוגמה לשינוי תכונה מופיעה ב-aosp/1345659.
- הדוגמה לרשימת הסמלים נמצאת ב-aosp/1346742.
- דוגמה לשינוי ב-XML של ABI מופיעה ב-aosp/1349377.
אם הסמל מיוצא (על ידכם או שהוא יוצא בעבר) אבל אף נהג אחר לא משתמש בו, ייתכן שתופיע הודעת שגיאה ב-build שדומה להודעה הבאה.
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
כדי לפתור את הבעיה, מעדכנים את רשימת הסמלים של KMI גם בליבה וגם ב-ACK (ראו עדכון הייצוג של ABI). דוגמה לעדכון של קובץ ה-XML של ה-ABI ורשימת הסמלים ב-ACK מופיעה ב-aosp/1367601.
פתרון תקלות ABI בליבה (kernel)
כדי לטפל בבעיות ABI בליבה, אפשר לבצע ריפרקטורינג של הקוד כך שלא ישנה את ה-ABI או לעדכן את הייצוג של ה-ABI. התרשים הבא יעזור לכם לקבוע את הגישה המתאימה ביותר למצב שלכם.
איור 1. רזולוציה של שבירת ABI
שינוי הקוד כדי למנוע שינויים ב-ABI
כדאי לעשות כמיטב יכולתכם כדי להימנע משינוי של ה-ABI הקיים. במקרים רבים, אפשר לבצע רפקטורינג של הקוד כדי להסיר שינויים שמשפיעים על ה-ABI.
שינוי שדות של מבנה (struct) אם שינוי משנה את ה-ABI של תכונת ניפוי באגים, מוסיפים
#ifdefסביב השדות (במבנים ובהפניות למקור) ומוודאים שה-CONFIGשמשמש את ה-#ifdefמושבת ב-defconfig של הייצור וב-gki_defconfig. דוגמה לאופן שבו אפשר להוסיף הגדרת debug ל-struct בלי לשבור את ה-ABI מופיעה בחבילת התיקונים הזו.ארגון מחדש של התכונות כך שלא ישנו את הליבה (kernel) של הליבה. אם צריך להוסיף תכונות חדשות ל-ACK כדי לתמוך במודולים של השותפים, נסו לבצע רפרסוקציה של החלק של ABI בשינוי כדי להימנע משינוי של ABI הליבה. דוגמה לשימוש ב-ABI הקיים של הליבה כדי להוסיף יכולות נוספות בלי לשנות את ה-ABI של הליבה מופיעה ב-aosp/1312213.
תיקון ממשק ABI לא תקין ב-Android Gerrit
אם לא שברתם בכוונה את ה-ABI של הליבה, תצטרכו לבדוק את הנושא בעזרת ההנחיות בכלי המעקב של ה-ABI. הסיבות הנפוצות ביותר לשיבושים הן שינויים במבנה הנתונים וב-CRC של הסמל המשויך, או שינויים באפשרויות התצורה שמובילים לאחד מהגורמים שצוינו למעלה. מתחילים לטפל בבעיות שהכלי מצא.
אפשר לשחזר את הממצאים של ABI באופן מקומי. תוכלו לקרוא איך עושים זאת במאמר יצירת הליבה והייצוג שלה ב-ABI.
מידע על תוויות Linux-1
אם מעלים שינויים להסתעפות שמכילה KMI שהוקפא או סופי, השינויים חייבים לעבור את AbiAnalyzer כדי לוודא שהשינויים לא ישפיעו על ה-ABI היציב באופן בלתי תואם. במהלך התהליך, הפקודה AbiAnalyzer מחפשת את דוח ה-ABI שנוצר במהלך ה-build (build מורחב שמבצע את ה-build הרגיל ואז כמה שלבים של חילוץ והשוואה של ABI).
אם השדה AbiAnalyzer מוצא דוח לא ריק, המערכת מגדירה את התוויתlint-1 והשינוי נחסם משליחה עד לפתרון הבעיה, עד שה-patchset מקבל תווית Lint+1.
עדכון ה-ABI של הליבה
אם אי אפשר להימנע משינוי ה-ABI, צריך להחיל את שינויי הקוד, את ייצוג ה-ABI ואת רשימת הסמלים על ה-ACK. כדי לגרום ל-lint להסיר את הערך -1 ולא לשבור את התאימות של GKI, צריך לבצע את השלבים הבאים:
ממתינים לקבלת אישור Code-Review +2 על ערכת התיקונים.
משלבים את השינויים בקוד עם השינוי בעדכון ה-ABI.
העלאת שינויים בקוד ABI לאישור
העדכון של ה-ACK ABI תלוי בסוג השינוי שמבוצע.
אם שינוי ABI קשור לתכונה שמשפיעה על בדיקות CTS או VTS, בדרך כלל אפשר לבחור את השינוי ולשלוח אותו לאישור כפי שהוא. לדוגמה:
- יש צורך ב-aosp/1289677 כדי שהאודיו יפעל.
- aosp/1295945 היא הגרסה הנדרשת כדי ש-USB יפעל.
אם שינוי ב-ABI הוא בתכונה שאפשר לשתף עם ACK, אפשר לבחור את השינוי הזה ולשלוח אותו ל-ACK כפי שהוא. לדוגמה, השינויים הבאים לא נדרשים לבדיקה של CTS או VTS, אבל אפשר לשתף אותם עם ACK:
- aosp/1250412 הוא שינוי בתכונה התרמית.
- aosp/1288857 הוא שינוי ב-
EXPORT_SYMBOL_GPL.
אם שינוי ב-ABI כולל תכונה חדשה שלא צריך לכלול באישור, אפשר להוסיף את הסמלים לאישור באמצעות stub, כפי שמתואר בקטע הבא.
שימוש ב-stubs ל-ACK
צריך להשתמש ב-stubs רק בשינויים בליבה של הליבה שלא תורמים ל-ACK, כמו שינויים בביצועים ובצריכת החשמל. ברשימה הבאה מפורטות דוגמאות לקטעי קוד חלולים ולבחירות חלקיות ב-ACK ל-GKI.
גרסה ראשונית של תכונת Core-isolate (aosp/1284493). אין צורך ביכולות ב-ACK, אבל הסמלים צריכים להופיע ב-ACK כדי שהמודולים יוכלו להשתמש בהם.
סמל placeholder למודול הספק (aosp/1288860).
בחירה ידנית של ABI בלבד בתכונה של מעקב אחר אירועים מסוג
mmלכל תהליך (aosp/1288454). התיקון המקורי נבחר ל-ACK ולאחר מכן צומצם כך שיכלול רק את השינויים הנדרשים כדי לפתור את ההבדל ב-ABI עבורtask_structו-mm_event_count. התיקון הזה גם מעדכן את המאפייןmm_event_typeenum כך שיכיל את המאפיינים הסופיים.רשימה חלקית של שינויים ב-ABI של מבנה תרמי שנדרשו יותר מאשר הוספת שדות ה-ABI החדשים.
התיקון aosp/1255544 פתר את ההבדלים ב-ABI בין הליבה של השותף לבין ACK.
התיקון aosp/1291018 תיקן את הבעיות הפונקציונליות שזוהו במהלך בדיקת GKI של התיקון הקודם. התיקון כלל את האיפוס של המבנה של פרמטר החיישן כדי לרשום כמה תחומים תרמיים לחיישן אחד.
CONFIG_NL80211_TESTMODEשינויים ב-ABI (aosp/1344321). התיקון הזה הוסיף את השינויים הנדרשים במבנה ל-ABI ולוודא שהשדות הנוספים לא גרמו להבדלים פונקציונליים, כדי לאפשר לשותפים לכלול אתCONFIG_NL80211_TESTMODEבליבות הייצור שלהם ועדיין לשמור על תאימות ל-GKI.
אכיפת ה-KMI בזמן הריצה
ליבות GKI משתמשות באפשרויות ההגדרה TRIM_UNUSED_KSYMS=y ו-UNUSED_KSYMS_WHITELIST=<union
of all symbol lists>, שמגבילות את הסמלים המיוצאים (כמו סמלים שיוצאו באמצעות EXPORT_SYMBOL_GPL()) לסמלים שמפורטים ברשימת סמלים. כל שאר הסמלים לא מיוצאים, וטעינה של מודול שדורש סמל שלא מיוצא נדחית. ההגבלה הזו נאכפת בזמן ה-build, ורשומות חסרות מסומנות.
למטרות פיתוח, ניתן להשתמש ב-build של ליבה (kernel) של GKI שלא כולל חיתוך סמלים (כלומר, אפשר להשתמש בכל הסמלים שיוצאו בדרך כלל). כדי לאתר את הגרסאות האלה, מחפשים את הגרסאות של kernel_debug_aarch64 בכתובת ci.android.com.
אכיפת ה-KMI באמצעות ניהול גרסאות של מודולים
הליבה הכללית של תמונת הליבה (GKI) משתמשת בניהול גרסאות של מודולים (CONFIG_MODVERSIONS) כאמצעי נוסף לאכיפת התאימות של KMI בזמן הריצה. ניהול גרסאות של מודולים עלול לגרום לכשלים בבדיקת יתירות מחזורית (CRC) בזמן טעינת המודול, אם ה-KMI הצפוי של המודול לא תואם ל-KMI של vmlinux. לדוגמה, זוהי שגיאה אופיינית שמתרחשת בזמן טעינת המודול בגלל חוסר התאמה ב-CRC של הסמל 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 ''
שימושים בניהול גרסאות של מודולים
יש כמה סיבות לשימוש בגרסאות של מודולים:
ניהול גרסאות של מודולים מאפשר לזהות שינויים בחשיפה של מבנה הנתונים. אם מודולים משנים מבני נתונים אטומים, כלומר מבני נתונים שלא נכללים ב-KMI, הם יקרסו אחרי שינויים עתידיים במבנה.
לדוגמה, השדה
fwnodeב-struct device. השדה הזה חייב להיות אטום למודול כדי שלא יוכלו לבצע שינויים בשדות שלdevice->fw_nodeאו להניח הנחות לגבי הגודל שלו.עם זאת, אם מודול כולל את
<linux/fwnode.h>(באופן ישיר או עקיף), השדהfwnodeב-struct deviceכבר לא אטום אליו. לאחר מכן המודול יכול לבצע שינויים ב-device->fwnode->devאו ב-device->fwnode->ops. התרחיש הזה בעייתי מכמה סיבות:הוא יכול לשבור הנחות שקוד הליבה מבסס על מבני הנתונים הפנימיים שלו.
אם עדכון ליבה עתידי ישנה את
struct fwnode_handle(סוג הנתוניםfwnode), המודול לא יפעל יותר עם הליבה החדשה. בנוסף, לא יופיעו הבדלים ב-stgdiffכי המודול מפר את ה-KMI על ידי מניפולציה ישירה במבנים הפנימיים של הנתונים בדרכים שלא ניתן לתעד על ידי בדיקה של הייצוג הבינארי בלבד.
מודול נוכחי נחשב לא תואם ל-KMI כשהוא נטען במועד מאוחר יותר על ידי ליבה חדשה שאינה תואמת. ניהול גרסאות של מודולים מוסיף בדיקת זמן ריצה כדי למנוע טעינה בטעות של מודול שלא תואם KMI לליבה. הבדיקה הזו מונעת בעיות בזמן ריצה שקשה לנפות באגים מהן, ותאונות של הליבה שעשויות לנבוע מחוסר תאימות שלא זוהה ב-KMI.
הפעלת ניהול גרסאות של מודול מונעת את כל הבעיות האלו.
בדיקת אי התאמות של CRC ללא אתחול המכשיר
stgdiff משווה ומדווחת על אי-התאמות של CRC בין ליבות לבין הבדלים אחרים ב-ABI.
נוסף על כך, build של ליבה מלא עם CONFIG_MODVERSIONS מופעל יוצר קובץ Module.symvers כחלק מתהליך ה-build הרגיל. הקובץ הזה מכיל שורה אחת לכל סמל שיוצאו על ידי הליבה (vmlinux) והמודולים. כל שורה מורכבת מערך ה-CRC, שם הסמל, מרחב השמות של הסמל, השם של vmlinux או המודול שמייצא את הסמל וסוג הייצוא (לדוגמה, EXPORT_SYMBOL לעומת EXPORT_SYMBOL_GPL).
אפשר להשוות בין קובצי Module.symvers של ה-build של GKI לבין ה-build שלכם כדי לבדוק אם יש הבדלים ב-CRC בסמלים שיוצאו על ידי vmlinux. אם יש הבדל בערך ה-CRC בסמל כלשהו שמיוצא על ידי vmlinux וגם באחד מהמודולים שטוענים במכשיר, המודול לא נטען.
אם אין לכם את כל הארטיפקטים של ה-build, אבל יש לכם את קובצי ה-vmlinux של הליבה של GKI והליבה שלכם, תוכלו להשוות את ערכי ה-CRC לסמל ספציפי על ידי הרצת הפקודה הבאה בשני הליבה והשוואת הפלט:
nm <path to vmlinux>/vmlinux | grep __crc_<symbol name>
לדוגמה, הפקודה הבאה בודקת את ערך ה-CRC של הסמל module_layout:
nm vmlinux | grep __crc_module_layout
0000000008663742 A __crc_module_layout
פתרון אי-התאמות ב-CRC
כדי לפתור אי-התאמה של CRC בזמן טעינת מודול:
יוצרים את הליבה של GKI ואת הליבה של המכשיר באמצעות האפשרות
--kbuild_symtypes, כפי שמוצג בפקודה הבאה:tools/bazel run --kbuild_symtypes //common:kernel_aarch64_distהפקודה הזו יוצרת קובץ
.symtypesלכל קובץ.o. פרטים נוספים זמינים במאמרKBUILD_SYMTYPESב-Kleaf.ב-Android מגרסה 13 ואילך, כדי ליצור את הליבה של GKI ואת הליבה של המכשיר, מוסיפים את
KBUILD_SYMTYPES=1לפקודה שבה משתמשים כדי ליצור את הליבה, כפי שמתואר בפקודה הבאה:KBUILD_SYMTYPES=1 BUILD_CONFIG=common/build.config.gki.aarch64 build/build.shכשמשתמשים ב-
build_abi.sh,, הדגלKBUILD_SYMTYPES=1כבר מוגדר באופן מרומז.מחפשים את קובץ ה-
.cשבו הסמלים עם אי-התאמה ב-CRC מיוצאים, באמצעות הפקודה הבאה:cd common && git grep EXPORT_SYMBOL.*module_layout kernel/module.c:EXPORT_SYMBOL(module_layout);לקובץ
.cיש קובץ.symtypesתואם ב-GKI, וגם את ארטיפקטי ה-build של ליבה המכשיר. מאתרים את הקובץ.cבאמצעות הפקודות הבאות:cd out/$BRANCH/common && ls -1 kernel/module.* kernel/module.o kernel/module.o.symversions kernel/module.symtypesאלה המאפיינים של קובץ
.c:הפורמט של הקובץ
.cהוא שורה אחת (אולי ארוכה מאוד) לכל סמל.הערך
[s|u|e|etc]#בתחילת השורה מציין שהסמל הוא מסוג הנתונים[struct|union|enum|etc]. לדוגמה:t#bool typedef _Bool boolאם חסרה קידומת
#בתחילת השורה, הסמל הוא פונקציה. לדוגמה:find_module s#module * find_module ( const char * )
משווים בין שני הקבצים ומתקנים את כל ההבדלים.
מקרה 1: הבדלים שנובעים מהרשאות הגישה לסוג הנתונים
אם ליבה אחת שומרת סמל או סוג נתונים לא שקופים מהמודולים, והליבה השנייה לא, ההבדל הזה מופיע בין קובצי .symtypes של שתי הליבות. בקובץ .symtypes מאחד הליבות מופיע הערך UNKNOWN לסמל, ובקובץ .symtypes מהליבה השנייה מופיעה תצוגה מורחבת של הסמל או של סוג הנתונים.
לדוגמה, הוספת השורה הבאה לקובץ include/linux/device.h בליבה גורמת לחוסר התאמה ב-CRC, אחד מהם הוא עבור module_layout():
#include <linux/fwnode.h>
השוואת module.symtypes של הסמל הזה חושפת את ההבדלים הבאים:
$ 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 ] ; }
...
אם הערך של הליבה הוא UNKNOWN וליבה של GKI כוללת את התצוגה המורחבת של הסמל (סביר מאוד שלא), צריך למזג את הליבה המשותפת העדכנית ביותר של Android עם הליבה שלכם כדי להשתמש בבסיס הליבה העדכני ביותר של GKI.
ברוב המקרים, בליבה של GKI יש ערך UNKNOWN, אבל הליבה כוללת את הפרטים הפנימיים של הסמל בגלל שינויים שבוצעו בליבה (kernel). הסיבה לכך היא שאחד מהקבצים בליבה הוסיף #include שלא קיים בליבה של GKI.
לרוב, התיקון הוא פשוט הסתרת #include החדש מ-genksyms.
#ifndef __GENKSYMS__
#include <linux/fwnode.h>
#endif
אחרת, כדי לזהות את #include שגורם להבדל, מבצעים את הפעולות הבאות:
פותחים את קובץ הכותרת שמגדיר את הסמל או סוג הנתונים שיש להם את ההבדל הזה. לדוגמה, עורכים את
include/linux/fwnode.hשלstruct fwnode_handle.מוסיפים את הקוד הבא בחלק העליון של קובץ ה-header:
#ifdef CRC_CATCH #error "Included from here" #endifבקובץ
.cשל המודול שיש בו אי-התאמה ב-CRC, מוסיפים את הטקסט הבא כשורה הראשונה לפני כל אחת מהשורות#include.#define CRC_CATCH 1עורכים את המודול. השגיאה שנובעת מכך בזמן ה-build מציגה את שרשרת קובץ הכותרת
#includeשהובילה לחוסר ההתאמה ב-CRC. לדוגמה: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"אחד הקישורים בשרשרת הזו של
#includeנובע משינוי שבוצע בליבה (kernel) שלך, שחסרה בליבה (kernel) של GKI.מזהים את השינוי, מבטלים אותו בליבה או מעלים אותו ל-ACK ומבצעים מיזוג.
מקרה 2: הבדלים עקב שינויים בסוג הנתונים
אם אי-התאמת ה-CRC לסמל או לסוג נתונים לא נובעת מהבדל בחשיפה, היא נובעת משינויים בפועל (הוספות, הסרות או שינויים) בסוג הנתונים עצמו.
לדוגמה, ביצוע השינוי הבא בליבה גורם לכמה אי-התאמות של CRC, כי הרבה סמלים מושפעים באופן עקיף מהשינוי הזה:
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);
אי-התאמה אחת של CRC היא עבור devm_of_platform_populate().
אם משווים בין קובצי .symtypes של הסמל הזה, התוצאה עשויה להיראות כך:
$ 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 * ) ; ...
כדי לזהות את הסוג שהשתנה, פועלים לפי השלבים הבאים:
מחפשים את ההגדרה של הסמל בקוד המקור (בדרך כלל בקובצי
.h).- כדי למצוא את ההבדלים בין הסמלים בליבה שלכם לבין הסמלים בליבה של GKI, מריצים את הפקודה הבאה:
git blame- לסמלים שנמחקו (כשהסמל נמחק בעץ ואתם רוצים למחוק אותו גם בעץ האחר), צריך לאתר את השינוי שמחק את השורה. משתמשים בפקודה הבאה בעץ שבו השורה נמחקה:
git log -S "copy paste of deleted line/word" -- <file where it was deleted>בודקים את רשימת ההתחייבויות שהוחזרו כדי לאתר את השינוי או את המחיקה. סביר להניח שההתחייבות הראשונה היא זו שאתם מחפשים. אם הוא לא מופיע, צריך לעבור על הרשימה עד שמוצאים את השמירה.
אחרי שמזהים את השינוי, אפשר לבטל אותו בליבה (kernel) או להעלות אותו ל-ACK ולמזג אותו.