Google is committed to advancing racial equity for Black communities. See how.
דף זה תורגם על ידי Cloud Translation API.
Switch to English

תמונת ליבה כללית

ליבות ה- Android Common Kernels (ACK) הן הבסיס לכל גרעיני מוצרי Android. גרעיני ספק ומכשירים נמצאים במורד הזרם של ACKs. ספקים מוסיפים תמיכה עבור SoC והתקנים היקפיים על ידי שינוי קוד המקור של הליבה והוספת מנהלי התקנים. שינויים אלה יכולים להיות נרחבים, עד כדי כך עד 50% מהקוד הפועל במכשיר הוא קוד מחוץ לעץ (לא מלינוקס במעלה הזרם או מגרעינים נפוצים של AOSP).

לפיכך, גרעין מכשיר מורכב מ:

  • במעלה הזרם: ליבת לינוקס מ- kernel.org
  • AOSP: תיקונים נוספים ספציפיים ל- Android מגרעינים נפוצים של AOSP
  • ספק: תיקוני הפעלה ואופטימיזציה היקפיים של SoC והיקפיים מספקים
  • OEM / התקן: מנהלי התקנים והתאמות אישיות נוספות

כמעט לכל מכשיר יש גרעין מותאם אישית. זהו פיצול גרעינים.

היררכיית ליבות אנדרואיד מובילה לפיצול

איור 1. היררכיית ליבות אנדרואיד מובילה לפיצול

עלויות הפיצול

לפיצול ליבה יש כמה השפעות שליליות על קהילת Android.

עדכוני האבטחה הם עתירי עבודה

יש להחזיר את תיקוני האבטחה המצוטטים בעלון האבטחה של Android (ASB) לכל אחד מגרעיני המכשיר. עם זאת, עקב פיצול גרעינים, יקר להפליא להפיץ תיקוני אבטחה למכשירי Android בשטח.

קשה למזג עדכונים נתמכים לטווח ארוך

המהדורות הנתמכות לטווח ארוך (LTS) כוללות תיקוני אבטחה ותיקוני באגים קריטיים אחרים. התעדכנות במהדורות LTS הוכיחה את עצמה כדרך היעילה ביותר לספק תיקוני אבטחה. במכשירי פיקסל התגלה כי 90% מבעיות האבטחה של הליבה שדווחו ב- ASB כבר תוקנו למכשירים שנשארים מעודכנים.

עם זאת, עם כל השינויים המותאמים אישית בגרעיני ההתקן, קשה פשוט למזג את תיקוני ה- LTS לליבות המכשיר.

מעכב שדרוגים לשחרור פלטפורמת Android

שבר מקשה על תכונות אנדרואיד חדשות המחייבות להוסיף שינויים בגרעין למכשירים בשטח. קוד Android Framework חייב להניח כי עד חמש גרסאות ליבה נתמכות ושלא בוצעו שינויי גרעין למהדורת הפלטפורמה החדשה (אנדרואיד 10 תומך בגרעיני 3.18, 4.4, 4.9, 4.14 ו- 4.19, שבמקרים מסוימים לא היו משופרת בתכונות חדשות מאז אנדרואיד 8 בשנת 2017).

קשה לתרום שינויי ליבה בחזרה לינוקס במעלה הזרם

עם כל השינויים שבוצעו בקרנל, מרבית מכשירי הדגל נשלחים עם גרסת ליבה שכבר בת 18 חודשים לפחות. לדוגמה, ליבת 4.14 שוחררה על ידי kernel.org בנובמבר 2017 והטלפונים האנדרואידיים הראשונים המשתמשים בגרעיני 4.14 נשלחו באביב 2019.

העיכוב הרב הזה בין שחרור ליבות במעלה הזרם לבין מוצרים מקשה על קהילת אנדרואיד להזין את התכונות והנהגים הדרושים לגרעינים במעלה, ולכן זה מאתגר לתקן את בעיית הפיצול.

תיקון הפיצול: תמונת ליבה כללית

הפרויקט Generic Kernel Image (GKI) מטפל בפיצול גרעינים על ידי איחוד גרעין הליבה והעברת תמיכת SoC ולוחות מתוך ליבת הליבה למודולים הניתנים לטעינה. ליבת GKI מציגה ממשק מודול ליבה (KMI) יציב עבור מודולי ליבות, כך שניתן לעדכן את המודולים והליבה באופן עצמאי.

ה- GKI:

  • בנויה מהמקורות ACK.
  • הוא בינארי יחיד של ליבות בתוספת מודולים הניתנים לטעינה לכל ארכיטקטורה, לכל מהדורת LTS (כרגע רק arm64 עבור android11-5.4 ו- android12-5.4 ).
  • נבדק עם כל גרסות פלטפורמת אנדרואיד הנתמכים עבור ACK הנלווה. אין הוצאה משימוש בתכונות לכל אורך החיים של גרסת ליבת GKI
  • חושף KMI יציב לנהגים בתוך LTS נתון.
  • אינו מכיל קוד ספציפי ל- SoC או ללוח.

כך נראה מכשיר אנדרואיד עם יישום GKI.

ארכיטקטורת GKI

איור 2. ארכיטקטורת GKI

GKI הוא שינוי מורכב שיגולגל בכמה שלבים החל מגרעיני v5.4 במהדורת פלטפורמת אנדרואיד 11.

GKI 1.0 - דרישות תאימות ל- GKI

עבור מכשירים מסוימים המושקים עם גרסת פלטפורמת אנדרואיד 11, תאימות טרבל מחייבת בדיקת GKI למכשירים המריצים גרעיני v5.4.

מחיצות לבדיקת תאימות GKI

איור 3. מחיצות לבדיקת תאימות GKI

GKI אמצעי תאימות המכשיר מעביר את VTS ו- CTS-על-GSI + GKI בדיקות עם תמונה מערכת גנרי (GSI) ואת הקרנל GKI מותקן על ידי מהבהבים תמונת האתחול GKI לתוך boot החלוקה תמונת מערכת GSI של system החלוקה. התקנים יכולים לשלוח עם גרעין מוצרים אחר ויכולים להשתמש במודולים הניתנים לטעינה ש- GKI אינו מספק. עם זאת, הן על ליבות המוצר והן על ליבות GKI חייבים לטעון מודולים מאותן מחיצות vendor vendor_boot . לכן, כל גרעיני המוצרים נדרשים לאותו ממשק מודול ליבה בינארי (KMI). ספקים יכולים להרחיב את KMI עבור גרעיני מוצרים כל עוד הוא נשאר תואם ל- KKI של GKI. אין דרישה שניתן יהיה לפרוק מודולי ספקים ב- GKI 1.0.

GKI 1.0 שערים

  • אל תציג רגרסיות ב- VTS או CTS כאשר גרעין המוצר מוחלף על ידי ליבת GKI.
  • צמצם את נטל תחזוקת הגרעינים עבור יצרני יצרנים וספקים להתעדכן בגרעינים נפוצים של AOSP.
  • כלול שינויים מרכזיים ב- Android בגרעינים בין אם מכשיר משודרג למהדורה חדשה של פלטפורמת Android או שהושק לאחרונה.
  • לעולם אל תשבר את מרחב המשתמשים של Android.
  • הפרד רכיבים ספציפיים לחומרה מליבת הליבה כמודולים הניתנים לטעינה.

GKI 2.0 - מוצרי GKI

חלק מהמכשירים המושקים עם Android S (ניסוי AOSP) (2021) משחררים פלטפורמת גרסאות גרעין v5.10 ומעלה נדרשים למשלוח עם ליבת GKI. תמונות אתחול חתומות יהיו זמינות ומתעדכנות באופן קבוע עם LTS ותיקוני באגים קריטיים. מכיוון שהיציבות הבינארית תישמר עבור ה- KMI, ניתן להתקין תמונות אתחול אלה ללא שינויים בתמונות הספק.

GKI 2.0 שערים

  • אל תציג ביצועים משמעותיים או רגרסיות כוח עם GKI.
  • אפשר ליצרני יצרן OEM לספק תיקוני אבטחה של ליבות ותיקוני באגים (LTS) ללא מעורבות ספק.
  • צמצום העלות של עדכון גרסת הליבה העיקרית למכשירים (למשל מ- v5.10 לליבת ה- LTS 2021).
  • שמור על גרסאות בינאריות של ליבת GKI אחת בלבד לכל ארכיטקטורה על ידי עדכון גרסאות הליבה בתהליך ברור לשדרוג.

עיצוב GKI

ענפי גרעיני KMI

גרעיני GKI בנויים מענפי הליבה של KK ACMI, המתוארים בפירוט בגרעיני Common Common . ה- KMI מזוהה באופן ייחודי על ידי גרסת הליבה <androidRelease>-<kernel version> פלטפורמת Android, ולכן הסניפים נקראים <androidRelease>-<kernel version> . לדוגמא, ענף הליבה KMI 5.4 לאנדרואיד 11 נקרא android11-5.4. צפוי כי ל- Android S (ניסוי AOSP) (לא מחויב ומוצג רק כדי להדגים כיצד יתקדם דגם android12-5.4 החדש בעתיד) יהיו שני גרעיני KMI נוספים, android12-5.4 שני המבוסס על ליבת LTS החדשה. , שאמור להיות מוכרז בסוף 2020.

היררכיית ליבות KMI

איור 4 מציג את היררכיית הענפים של גרעיני KMI 5.10. android12-5.10 הוא ליבת KMI המתאימה ל- Android S (AOSP ניסיוני) ו- android13-5.10 תואמת ל- Android T (AOSP ניסוי) (לא מחויבת ומוצגת רק כדי להדגים כיצד יתקדם דגם הסניף החדש בעתיד).

היררכיית ליבות KMI למשך 5.10

איור 4. היררכיית ליבת KMI למשך 5.10

כפי שמוצג באיור 4, ענפי KMI עוברים בשלושה שלבים: פיתוח (התפתחות), ייצוב (דקירה) וקפוא . שלבים אלה מתוארים בפירוט בגרעינים הנפוצים של Android .

לאחר הקפאת ליבת KMI, לא יתקבלו שינויים בשבירת KMI אלא אם כן זוהה בעיית אבטחה חמורה שלא ניתן להקל עליה מבלי להשפיע על KMI היציב. הסניף נותר קפוא לאורך כל חייו.

ניתן לקבל תיקוני באגים ותכונות של שותפים לסניף קפוא כל עוד ה- KMI הקיים אינו מקולקל. ניתן להרחיב את ה- KMI באמצעות סמלים מיוצאים חדשים כל עוד הממשקים הכוללים את ה- KMI הנוכחי אינם מושפעים. כאשר ממשקים חדשים מתווספים ל- KMI, הם הופכים מיד ליציבים ולא יכולים להישבר על ידי שינויים עתידיים.

לדוגמא, שינוי שמוסיף שדה למבנה שמשמש ממשק KMI אינו מורשה מכיוון שהוא משנה את הגדרת הממשק:

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

עם זאת, הוספת פונקציה חדשה זה בסדר:

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

יציבות KMI

כדי לממש את יעדי ה- GKI, חשוב לשמור על KMI יציב לנהגים. ליבת GKI בנויה ונשלחת בצורה בינארית, אך מודולים הניתנים לטעינת ספק בנויים בעץ נפרד. ליבת GKI והמודולים המתקבלים חייבים לעבוד כאילו הם בנויים יחד. לבדיקת תאימות GKI, תמונת האתחול המכילה את הליבה מוחלפת בתמונת אתחול המכילה את ליבת GKI, ועל המודולים הניתנים לטעינה בתמונת הספק לפעול כהלכה עם גרעין זה או אחר.

ה- KMI אינו כולל את כל הסמלים בגרעין או אפילו את כל 30,000+ הסמלים המיוצאים. במקום זאת, הסמלים שניתן להשתמש בהם על ידי מודולים מפורטים במפורש בקבוצה של קבצי רשימת סמלים המתוחזקים באופן ציבורי בשורש עץ הליבה. איחוד כל הסמלים בכל קבצי רשימת הסמלים מגדיר את קבוצת סמלי ה- KMI הנשמרת יציבה. קובץ רשימת סמלים לדוגמא הוא abi_gki_aarch64_db845c , שמצהיר על הסמלים הדרושים ל- DragonBoard 845c .

רק הסמלים המופיעים ברשימת סמלים והמבנים וההגדרות הקשורים אליהם נחשבים כחלק מ- KMI. אתה יכול לפרסם שינויים ברשימות הסמלים שלך אם הסמלים שאתה צריך אינם נמצאים. לאחר שממשקים חדשים נמצאים ברשימת סמלים, ולכן הם חלק מתיאור ה- KMI, הם נשמרים יציבים ואסור להסיר אותם מרשימת הסמלים או לשנות אותם לאחר הקפאת הענף.

לכל עץ גרעין של KMI קבוצה משלו של רשימות סמלים. לא נעשה ניסיון לספק יציבות ABI בין ענפי גרעיני KMI שונים. לדוגמה, ה- KMI android11-5.4 אינו תלוי לחלוטין ב- KMI android12-5.4 .

באופן כללי, קהילת לינוקסקימט את מצחו של הרעיון של יציבות ABI בתוך הליבה עבור הליבה המרכזית. לנוכח שרשראות כלים שונות, תצורות וגרעין הלינה הראשי של לינוקס המתפתח תמיד, לא ניתן לשמור על KMI יציב בקו הראשי. עם זאת, זה אפשרי בסביבת GKI מוגבלת מאוד. האילוצים הם:

  • ה- KMI יציב רק בתוך אותו גרעין LTS (לדוגמה, android11-5.4 ).
    • אין שמירה על יציבות KMI עבור android-mainline .
  • רק שרשרת הכלים הספציפית של Clang המסופקת ב- AOSP ומוגדרת לענף המקביל משמשת לבניית גרעינים ומודולים.
  • רק סמלים הידועים כמשמשים את המודולים כמפורט ברשימת סמלים מנוטרים ליציבות ונחשבים לסמלי KMI.
    • המסקנה היא שעל המודולים להשתמש בסמלי KMI בלבד. הדבר נאכף על ידי טעינת מודולים כושלת אם נדרשים סמלים שאינם של KMI.
  • לאחר הקפאת סניף KMI, אין שינויים שיכולים לשבור את KMI, כולל:
    • שינויים בתצורה
    • קוד הליבה משתנה
    • שינויים בשרשרת הכלים (כולל עדכונים)

ניטור KMI

כלי ניטור ABI עוקבים אחר יציבות KMI במהלך בדיקות הגשה מראש. שינויים המפרקים את ה- KMI נכשלים בבדיקות הגישה המוקדמת ויש לעבד אותם מחדש כדי שיהיו תואמים. כלים אלה עומדים לרשות השותפים והציבור לשילוב בתהליכי הבנייה שלהם. צוות הליבה של Android משתמש בכלים אלה כדי למצוא שברי KMI במהלך הפיתוח ובמיזוג מהדורות LTS. אם מתגלה שבר ב- KMI במהלך מיזוג LTS, ה- KMI נשמר על ידי הסרת התיקונים הפוגעים או על ידי שיקום מחדש של התיקונים כך שיהיו תואמים.

ה- KMI נחשב כשבור אם משתנה סמל KMI קיים באופן שאינו תואם. דוגמאות:

  • טיעון חדש נוסף לפונקציה KMI
  • שדה חדש נוסף למבנה המשמש פונקציית KMI
  • ערך נוסף של enum המשנה את ערכי ה- enums המשמשים פונקציית KMI
  • שינוי תצורה המשנה את נוכחותם של חברי הנתונים המשפיעים על ה- KMI

הוספת סמלים חדשים לא בהכרח שוברת את KMI, אך יש להוסיף סמלים חדשים המשמשים לרשימת הסמלים ולייצוג ABI. אחרת שינויים עתידיים בחלק זה של ה- KMI לא יוכרו.

השותפים צפויים להשתמש בכלי הניטור של ABI כדי להשוות את ה- KMI בין ליבת המוצרים שלהם לבין ליבת GKI ולהבטיח שהם תואמים.

ניתן להוריד את ליבת ה- GKI הבינארית android11-5.4 האחרונה מ- ci.android.com ( kernel_aarch64 builds).

מהדר יחיד

שינוי מהדר יכול לשנות את פריסת מבנה נתוני הליבה הפנימית המשפיעה על ה- ABI. מכיוון שחשוב לשמור על יציבות KMI, שרשרת הכלים המשמשת לבניית ליבת GKI חייבת להיות תואמת לחלוטין לשרשרת הכלים המשמשת לבניית מודולים של ספקים. ליבת GKI בנויה עם שרשרת הכלים LLVM הכלולה ב- AOSP.

החל מאנדרואיד 10, כל גרעיני Android חייבים לבנות עם שרשרת כלים LLVM. עם GKI, שרשרת הכלים LLVM המשמשת לבניית גרעיני מוצרים ומודולי ספקים חייבת ליצור אותו ABI כמו שרשרת הכלים LLVM מבית AOSP והשותפים חייבים לוודא שה- KMI תואם לליבת GKI.

תיעוד בניית הליבה של Android מתאר כיצד בנוי ליבת ה- GKI. בפרט, ההליך המתועד מבטיח כי שרשרת הכלים והתצורה הנכונים משמשים לבניית הגרעין. שותפים במורד הזרם מוזמנים להשתמש באותם כלים לייצור הגרעין הסופי כדי למנוע אי התאמות הנגרמות על ידי שרשרת כלים או תלות אחרת בזמן הבנייה.

הגרעין מוגדר

ליבת GKI בנויה באמצעות arch/arm64/configs/gki_defconfig . מכיוון שהתצורות הללו משפיעות על ה- KMI, התצורות של GKI מנוהלות בזהירות רבה. עבור גרעיני KMI קפואים, ניתן להוסיף או להסיר configs רק אם אין השפעה על KMI.

יש להגדיר את ליבת GKI להפעלה על קבוצה מגוונת של מכשירים. לכן עליו להיות בעל תמיכה מובנית בכל מערכות המשנה והאפשרויות הנדרשות לכל המכשירים הללו, לא כולל המודולים הניתנים לטעינה המשמשים להפעלת החומרה. על השותפים לבקש את שינויי התצורה הדרושים לגרעיני dev.

שינויים באתחול

כדי להקל על הפרדה נקייה בין רכיבי GKI לבין ספק, מחיצת boot מכילה רק רכיבים כלליים, כולל הליבה ו- ramdisk עם מודולי GKI. מוגדרת גרסה חדשה של כותרת האתחול (v3) המעידה על תאימות לארכיטקטורת GKI. גרסת ה- GKI של תמונות האתחול מועברת על ידי גוגל ומחליפה את גרסת הספק של תמונת האתחול בעת בדיקת תאימות ל- GKI.

ה- ramdisk עבור init , recovery ו- fastbootd בשלב הראשון הוא תמונה initramfs המורכבת משני ארכיוני CPIO המצורפים על ידי מנהל האתחול. ארכיון ה- vendor_boot הראשון מגיע vendor_boot החדשה vendor_boot . השנייה מגיעה ממחיצת boot .

סיכום השינויים ניתן כאן. לפרטים עיין במחיצת אתחול הספק .

מחיצת אתחול

מחיצת boot כוללת כותרת, גרעין וארכיון CPIO של החלק הגנרי של ה- ramdisk האתחול.

עם v3 אתחול כותרת boot מחיצה, סעיפים אלה לפני boot המחיצה אינם שוהה:

  • מאתחל שלב שני: אם למכשיר יש מאתחל שלב שני, עליו לאחסן אותו במחיצה משלו.
  • DTB: ה- DTB מאוחסן במחיצת אתחול הספק .

מחיצת boot מכילה ארכיון CPIO עם רכיבי GKI:

  • מודולי ליבת GKI הממוקמים ב- /lib/modules/
  • first_stage_init וספריות זה תלוי
  • fastbootd recovery (משמש במכשירי A / B ו- A / B וירטואליים)

תמונת האתחול של GKI מסופקת על ידי גוגל ויש להשתמש בה לצורך בדיקת תאימות של GKI .

את הגרסה האחרונה של arm64 android11-5.4 boot.img ניתן להוריד מ- ci.android.com aosp_arm64 הבנייה aosp_arm64 של aosp-master ה- aosp-master .

את תמונת הליבה האחרונה של אנדרואיד android11-5.4 arm64 ( Image.gz ) ניתן להוריד מ- ci.android.com בענפי הבניין kernel_aarch64 של ענף aosp_kernel-common-android11-5.4 .

מחיצת אתחול הספק

מחיצת vendor_boot מוצגת עם GKI. זה A / B'd עם A / B וירטואלי ומורכב מכותרת עליונה, ramdisk הספק וכתם עץ המכשיר. Ramdisk הספק הוא ארכיון CPIO המכיל את מודולי הספק הנדרשים לצורך אתחול המכשיר. זה כולל מודולים המאפשרים פונקציונליות SoC קריטית, כמו גם מנהלי אחסון ותצוגה הדרושים לאתחול ההתקן ולהצגת מסכי התזה.

ארכיון CPIO מכיל:

  • השלב הראשון init ספק הקרנל מודולים ממוקמים /lib/modules/
  • קבצי תצורה של modprobe הממוקמים ב- /lib/modules
  • modules.load קובץ המציין את המודולים לטעון במהלך init בשלב הראשון

דרישת Bootloader

על מנהל האתחול לטעון את תמונת ה- CPD הגנרית של ramdisk ( ממחיצת boot ) לזיכרון מיד לאחר תמונת ה- ramdisk vendor_boot של הספק ( ממחיצת vendor_boot ). לאחר שחרור לחץ, התוצאה היא ה- ramdisk הגנרי המונח על גבי מבנה הקבצים של ramdisk הספק.

בדיקות תאימות של GKI

לצורך הפצת פלטפורמת אנדרואיד 11, מכשירים שהושקו עם ליבת v5.4 חייבים להריץ את בדיקות VTS ו- CTS-on-GSI באמצעות תמונת האתחול של GKI שמספקת גוגל.

תורם לליבת ה- GKI

ליבת GKI בנויה מ- AOSP android11-5.4 Common החל מ- android11-5.4 . כל התיקונים שהוגשו חייבים להתאים להנחיות התרומה הללו , המתעדות שתי אסטרטגיות:

  1. הטוב ביותר: בצע את כל השינויים שלך במערכת הלינוקס במעלה הזרם. אם מתאים, חזור אל המהדורות היציבות. תיקונים אלה מוזגו אוטומטית בגרעינים המקובלים של AOSP. אם התיקון כבר נמצא במעלה לינוקס, פרסם יציאה אחורית של התיקון שתואם את דרישות התיקון שלהלן.
  2. פחות טוב: פתח את התיקונים שלך מהעץ (מנקודת מבט של לינוקס במעלה). אלא אם כן התיקונים מתקנים באג ספציפי לאנדרואיד, סביר מאוד שהם לא יתקבלו אלא אם הם מתואמים עם kernel-team@android.com .

עבור שותפים המיישמים GKI, יכולות להיות סיבות תקפות לכך שנדרשים טלאים מחוץ לעץ (במיוחד אם יש לוחות זמנים של סיליקון שיש לעמוד בהם). במקרים אלה, הגש בעיה של Buganizer .

הגש שינויים ב- GKI דרך Gerrit לראשונה לסניף android-mainline קווין ואז חזור לסניפי שחרור אחרים לפי הצורך.

אין צורך לתרום את קוד המקור המשויך למודולים הניתנים לטעינה לעץ מקור הליבה של GKI, אולם מומלץ בחום להגיש את כל מנהלי ההתקנים ללינוקס במעלה הזרם.

בקשת חזרות אחוריות מהקו הראשי

באופן כללי, ניתן להחזיר את התיקונים המרכזיים הדרושים לשותפי GKI לליבות ה- GKI. העלה את התיקון לגריט בהתאם להנחיות התרומה .

אם התיקון פורסם במעלה הזרם, אך טרם התקבל, מומלץ להמתין עד לקבלתו. אם לוח הזמנים אינו מאפשר המתנה לקבלת התיקון במעלה הזרם, הגש בעיה של Buganizer.

הוספה והסרה של תצורות GKI

כדי לבקש הוספה או הסרה של configs ב- arch/arm64/configs/gki_defconfig , הגש סוגיה של Buganizer המציינת בבירור את הבקשה והצדקה. אם אין פרויקט נגיש של Buganizer, פרסם את התיקון עם שינוי התצורה לגריט וודא שהודעת ההתחייבות מציינת בבירור את הסיבה שיש צורך בתצורה.

שינויי תצורה בגרעיני KMI קפואים אינם יכולים להשפיע על KMI.

שינוי קוד הליבה הליבה

שינויים בקוד הליבה של הליבות בגרעינים הנפוצים של AOSP אינם מודעים. ראשית שלח טלאים למעלה לינוקס במעלה הזרם ואז אחזור אותם. אם יש סיבה טובה לשינוי גרעין הליבה, הגש סוגיה של Buganizer המציינת בבירור את הבקשה והצדקה. לא מתקבלות תכונות ספציפיות לאנדרואיד ללא בעיה של Buganizer. שלח דוא"ל לכתובת kernel-team@android.com אם אינך יכול ליצור בעיה של Buganizer.

ייצוא סמלים באמצעות EXPORT_SYMBOL_GPL ()

אל תשלח טלאים במעלה הזרם המכילים ייצוא סמלים בלבד. כדי להיחשב עבור לינוקס במעלה הזרם, תוספות של EXPORT_SYMBOL_GPL() מחייבות מנהל התקן מודולרי בתוך העץ שמשתמש בסמל, לכן EXPORT_SYMBOL_GPL() את מנהל ההתקן החדש או שינויים במנהל התקן קיים באותו ערכת תיקונים כמו הייצוא.

בעת שליחת טלאים במעלה הזרם, על הודעת ההתחייבות להכיל הצדקה ברורה מדוע התיקון נחוץ ומועיל לקהילה. הפעלת ייצוא לטובת מנהלי התקנים או פונקציונליות מחוץ לעץ אינה טיעון משכנע לתומכים במעלה הזרם.

אם מסיבה כלשהי לא ניתן לשלוח את התיקון במעלה הזרם, הגש בעיה של Buganizer והסבר מדוע לא ניתן לשלוח את התיקון במעלה הזרם. ככלל, סמלים המהווים ממשק נתמך למערכת משנה ליבה עשויים להתקבל כיצוא. עם זאת, סביר להניח שלא יתקבלו פונקציות עוזרות פנימיות אקראיות ותתבקש לשקם את קודך מחדש על מנת להימנע משימוש בהן.

הוספת סמל לרשימת סמלי KMI

יש לעדכן את רשימות הסמלים של KMI עם סמלי ליבת GKI המשמשים את מודולי הספק. מכיוון שרק סמלי KMI נשמרים יציבים, GKI אינו מאפשר לטעון מודולים אם הם מסתמכים על סמל שאינו KMI.

סקריפט extract_symbols מחלץ את הסמלים הרלוונטיים מעץ בניית גרעין וניתן להשתמש בו לעדכון רשימת סמלי KMI. לקבלת פרטים נוספים, עיין בתיעוד עם רשימת הסמלים .