פיתוח קוד ליבה ל-GKI

תמונת הליבה הכללית (GKI) מקטינה את פיצול הליבה על ידי התאמה קרובה עם הליבה של Linux במעלה הזרם. עם זאת, יש סיבות לגיטימיות תיקונים מסוימים לא זמינים ב-upstream, ויש לוחות זמנים של מוצרים ולכן חלק מהתיקונים מתוחזקים בליבה (Kernel) של Android Common (ACK) שמהם נבנה ה-GKI.

מפתחים צריכים לשלוח שינויים בקוד למקור (upstream) באמצעות רשימת התפוצה של Linux Kernel (LKML) כאפשרות הראשונה, ולשלוח שינויים בקוד להסתעפות ACKandroid-mainline רק אם יש סיבה טובה לכך שהאפשרות של שליחה למקור לא מתאימה. בהמשך מפורטות דוגמאות לסיבות תקפות ולדרכים לטפל בהן.

  • התיקון נשלח אל LKML, אבל לא התקבל בזמן למוצר מסוים גרסה חדשה. כדי לטפל בתיקון הזה:

    • יש לספק הוכחה לכך שהתיקון נשלח ל-LKML וקיבל תגובות, או ציון זמן משוער שבו התיקון יישלח ל-upstream.
    • להחליט על דרך פעולה להטמעת התיקון ב-ACK, לקבל אישור למעלה בזרם (upstream) ואז להסיר אותו מ-ACK כשהגרסה הסופית ב-upstream תשולב ב-ACK.

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

  • התיקון לא כללי מספיק להצגה ב-upstream ואין זמן להגדיר אותו מחדש לפני השקת המוצר. כדי לטפל בתיקון הזה, צריך לספק הזמן המשוער שבו יישלח תיקון שעבר ארגון מחדש ב-upstream התיקון לא יאושר ב-ACK ללא תוכנית לשליחה מחדש של הקוד (Refactoring) תיקון upstream לבדיקה).

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

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

דרישות לגבי תיקונים

התיקונים חייבים לעמוד בתקני הקוד של ליבה של Linux שמתוארים בעץ המקור של Linux, בין שהם נשלחים ל-upstream ובין שהם נשלחים ל-ACK. scripts/checkpatch.pl פועל כחלק מהבדיקות המקדימות ל-Gerrit, לכן צריך להריץ אותו מראש כדי מוודאים שהוא עובר. כדי להריץ את סקריפט checkpatch עם אותה הגדרה כמו בבדיקות המקדימות לשליחה, משתמשים ב-//build/kernel/static_analysis:checkpatch_presubmit. פרטים נוספים זמינים במאמר build/kernel/kleaf/docs/checkpatch.md.

תיקוני ACK

תיקונים שנשלחים ל-ACK חייבים לעמוד בסטנדרטים של קידוד ליבה (kernel) של Linux ההנחיות לגבי תרומות. יש לכלול Change-Id תג בהודעת ההתחייבות; אם שולחים את התיקון לכמה הסתעפויות (עבור לדוגמה, android-mainline ו-android12-5.4), עליך להשתמש באותם Change-Id לכל המופעים של התיקון.

קודם צריך לשלוח את התיקונים ל-LKML לבדיקה ב-upstream. אם התיקון:

  • אושר ב-upstream, והוא ימוזג באופן אוטומטי ל-android-mainline.
  • לא אושר ב-upstream, יש לשלוח אותו אל android-mainline עם התייחסות להגשת התוכן ב-upstream או הסבר מדוע היא לא נשלח אל LKML.

אחרי שתיקון מתקבל ב-upstream או ב-android-mainline, אפשר להעביר אותו לאחור (backport) למהדורת ה-ACK המתאימה מבוססת-LTS (למשל android12-5.4 ו-android11-5.4 לתיקונים שמתקנים קוד ספציפי ל-Android). שליחת בקשה ל-android-mainline מאפשרת בדיקה עם גרסאות מועמדות חדשות ל-upstream, ומבטיחה שהתיקון יהיה ב-ACK הבא שמבוסס על LTS. מקרים יוצאים מן הכלל שבו תיקון של upstream מועבר לאחור אל android12-5.4 (כי התיקון כנראה כבר נמצאים ב-android-mainline).

תיקונים ל-upstream

כפי שמפורט בהנחיות לשליחת תיקונים, תיקונים ב-upstream שמיועדים לליבת ACK נכללים בקבוצות הבאות (הרשימה מפורטת לפי הסבירות לקבלה).

  • UPSTREAM: – תיקונים שנבחרו בקפידה מ-'android-mainline' צפויים להתקבל ב-ACK אם יש להם תרחיש לדוגמה סביר.
  • BACKPORT: – תיקונים מרמת פליטת הגז שלא עושים סדר בניקיון וצריכים עשויים להתקבל שינויים גם אם קיים שימוש סביר מותאמת אישית.
  • FROMGIT: – תיקונים שנבחרו בצורה קפדנית מהסניף של המתחזקים בהכנה ולשלוח לנו את הבקשה הראשית של Linux, אם האחרון. צריך להצדיק את הבקשות האלה גם לגבי התוכן וגם לגבי לוח הזמנים.
  • FROMLIST: – תיקונים שנשלחו ל-LKML אבל עדיין לא אושרו להוספה להסתעפות של המנהל, לא צפויים להתקבל, אלא אם ההצדקה מספיק משכנעת כדי שהתיקון יתקבל גם אם הוא לא ייכלל ב-Linux למקור (אנחנו מניחים שהוא לא ייכלל). יש חייב להיות בעיה שמשויכת לתיקונים של FROMLIST כדי להקל על הדיון עם צוות הליבה של Android.

תיקונים ספציפיים ל-Android

אם לא ניתן להציג את השינויים הנדרשים ב-upstream, אפשר לנסות לשלוח תיקונים שאינם מעץ ל-ACK באופן ישיר. כדי לשלוח תיקונים מחוץ לעץ, צריך ליצור פנייה ב-IT עם ציון התיקון והסיבה לכך שלא ניתן לשלוח אותו למקור (דוגמאות מפורטות ברשימה הקודמת). עם זאת, יש כמה מקרים שבהם לא ניתן לשלוח את הקוד ל-upstream. הבקשות האלה מטופלות באופן הבא, ועליך לפעול בהתאם להנחיות לשליחת תיקונים ל-Android, ולתייג את הנושא בתחילית ANDROID:.

שינויים ב-gki_defconfig

צריך להחיל את כל השינויים של CONFIG בהגדרה gki_defconfig גם בזרוע 64 וגם בגרסאות x86, אלא אם CONFIG הוא ספציפי לארכיטקטורה. כדי לבקש שינוי בהגדרה של CONFIG, צריך ליצור פנייה ב-IT כדי לדון בשינוי. כל שינוי ב-CONFIG שמשפיע על ממשק מודול הליבה (KMI) אחרי שהוא קפוא נדחה. במקרים שבהם שותפים מבקשים הגדרות סותרות בתצורה אחת, אנחנו פותרים את הבעיות באמצעות דיון בבאגים הרלוונטיים.

קוד שלא קיים ב-upstream

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

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

מודולים מחוץ לעץ

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

לדוגמה, נניח שיש תיקון שמוסיף מאקרו EXPORT_SYMBOL_GPL(), והמודולים שמשתמשים בייצוא לא נמצאים בעץ המקור. אתם צריכים לנסות לבקש את EXPORT_SYMBOL_GPL() ב-upstream ולספק מודול שמשתמש בסמל שיוצאו לאחרונה. עם זאת, אם יש הצדקה תקפה לכך שהמודול לא נשלח ל-upstream, תוכלו לשלוח את התיקון ל-ACK במקום זאת. צריך לכלול בבעיה את ההצדקה לכך שלא ניתן להעביר את המודול ל-upstream. (אין לבקש את הווריאציה שאינה GPL, EXPORT_SYMBOL().)

הגדרות מוסתרות

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

כדי להפעיל הגדרה מוסתרת, מוסיפים משפט select בקובץ init/Kconfig.gki כדי שהיא תיבחר באופן אוטומטי על סמך הגדרת הליבה CONFIG_GKI_HACKS_TO_FIX, שמופעלת בקובץ gki_defconfig. יש להשתמש במנגנון הזה רק להגדרות מוסתרות. אם ההגדרה לא מוסתרת, צריך לציין אותה ב-gki_defconfig באופן מפורש או כיחסי תלות.

מושלים שניתן לטעון

ב-frameworks של ליבה (kernel) (כמו cpufreq) שתומכות במנהלים שניתנים לטעינה, צריך יכול לשנות את מושל ברירת המחדל (למשל, מושל schedutil של cpufreq. אם מדובר במסגרות (כמו המסגרת התרמית) שלא תומכות במנהלי התקנים או בדרייברים שניתן לטעון, אבל עדיין דורשות הטמעה ספציפית לספק, צריך ליצור דיווח ב-IT ולהתייעץ עם צוות הליבה של Android.

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

קטעי הוק (hooks) של ספקים

בגרסאות קודמות, אפשר היה להוסיף שינויים ספציפיים לספק ישירות לליבת הליבה. זה לא אפשרי ב-GKI 2.0, כי קוד ספציפי למוצר יוטמעו במודולים ולא יתקבלו בליבות הליבה ב-upstream, ב-ACK. כדי להפעיל תכונות עם ערך מוסף ששותפים מסתמכים עליהן, עם השפעה מינימלית בקוד הליבה של הליבה, GKI מקבל הוקים (hooks) של ספקים שמאפשרים להפעיל מודולים מקוד ליבה (kernel). בנוסף, אפשר למלא את מבני הנתונים של המפתחות בשדות של נתוני הספק שזמינים לאחסון נתונים ספציפיים לספק כדי להטמיע את התכונות האלה.

יש שני סוגים של ווקים של ספקים (רגילים ומסוגרים) שמבוססים על נקודות מעקב (לא אירועי מעקב) שמודולים של ספקים יכולים לצרף אליהם. לדוגמה, במקום להוסיף פונקציית sched_exit() חדשה לביצוע הנהלת חשבונות במשימה יציאה, ספקים יכולים להוסיף הוק ב-do_exit() שאליו מודול ספק יכול לחבר לעיבוד. דוגמה להטמעה כוללת את ה-hooks הבאים של הספק.

  • קטעי הוק (hooks) רגילים של ספק משתמשים ב-DECLARE_HOOK() כדי ליצור פונקציית tracepoint בשם trace_name, name הוא המזהה הייחודי של למעקב. לפי המוסכמה, שמות הוק (hooks) רגילים של ספקים מתחילים ב-android_vh, לכן השם של ההוק (hook) sched_exit() יהיה android_vh_sched_exit.
  • צריך להשתמש ב-hooks מוגבלים של ספקים במקרים כמו ווקים של מתזמן, שבהם צריך להפעיל את הפונקציה המצורפת גם אם המעבד (CPU) במצב אופליין או אם נדרש הקשר לא אטומי. אי אפשר לנתק ווקים מוגבלים של ספקים, ולכן תמיד יהיה אפשר לפרוק מודולים שמצורפים לווקים מוגבלים. מוצר שהצפייה בו הוגבלה שמות ה-hook של הספקים מתחילים ב-android_rvh.

כדי להוסיף הוק (hook) ספק, מדווחים על בעיה ב-IT ושולחים תיקונים (כמו עם כל תיקונים ספציפיים ל-Android, חייבת להיות בעיה וצריך לספק אותם הצדקה). התמיכה ב-hooks של ספקים קיימת רק ב-ACK, לכן אל תשלחו את התיקונים האלה ל-upstream Linux.

הוספת שדות של ספקים למבנים

אפשר לשייך נתוני ספק למבני נתונים מרכזיים על ידי הוספת android_vendor_data באמצעות פקודות המאקרו ANDROID_VENDOR_DATA(). עבור לדוגמה, כדי לתמוך בתכונות עם ערך מוסף, צרף שדות למבנים כפי שמוצג בדוגמת הקוד הבאה.

כדי למנוע התנגשויות פוטנציאליות בין השדות שנדרשים על ידי הספקים והשדות שנדרשים על ידי יצרני ה-OEM, אסור ליצרני ציוד מקורי להשתמש בשדות שהוצהרו באמצעות ANDROID_VENDOR_DATA() פקודות מאקרו. במקום זאת, יצרני ציוד מקורי צריכים להשתמש ב-ANDROID_OEM_DATA() כדי להצהיר על שדות android_oem_data.

#include <linux/android_vendor.h>
...
struct important_kernel_data {
  [all the standard fields];
  /* Create vendor data for use by hook implementations. The
   * size of vendor data is based on vendor input. Vendor data
   * can be defined as single u64 fields like the following that
   * declares a single u64 field named "android_vendor_data1" :
   */
  ANDROID_VENDOR_DATA(1);

  /*
   * ...or an array can be declared. The following is equivalent to
   * u64 android_vendor_data2[20]:
   */
  ANDROID_VENDOR_DATA_ARRAY(2, 20);

  /*
   * SoC vendors must not use fields declared for OEMs and
   * OEMs must not use fields declared for SoC vendors.
   */
  ANDROID_OEM_DATA(1);

  /* no further fields */
}

הגדרת קטעי הוק (hooks) של ספקים

הוספת ה-hooks של ספק לקוד ליבה (kernel) כנקודות מעקב על-ידי הצהרה עליהם באמצעות DECLARE_HOOK() או DECLARE_RESTRICTED_HOOK() ולאחר מכן מוסיפים אותם לקוד בתור נקודת מעקב. לדוגמה, כדי להוסיף את trace_android_vh_sched_exit() אל פונקציית הליבה (kernel) הקיימת של do_exit():

#include <trace/hooks/exit.h>
void do_exit(long code)
{
    struct task_struct *tsk = current;
    ...
    trace_android_vh_sched_exit(tsk);
    ...
}

הפונקציה trace_android_vh_sched_exit() בודקת בהתחלה רק אם יש משהו מצורף. עם זאת, אם מודול של ספק רושם טיפול באמצעות register_trace_android_vh_sched_exit(), הפונקציה הרשומה תופעל. ה-handler חייב להיות מודע להקשר בנוגע למנעולים מוחזקים, למצב RCS ול גורמים אחרים. צריך להגדיר את ה-hook בקובץ כותרת בספרייה include/trace/hooks.

לדוגמה, הקוד הבא מספק הצהרה אפשרית עבור trace_android_vh_sched_exit() בקובץ include/trace/hooks/exit.h.

/* SPDX-License-Identifier: GPL-2.0 */
#undef TRACE_SYSTEM
#define TRACE_SYSTEM sched
#define TRACE_INCLUDE_PATH trace/hooks

#if !defined(_TRACE_HOOK_SCHED_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_HOOK_SCHED_H
#include <trace/hooks/vendor_hooks.h>
/*
 * Following tracepoints are not exported in tracefs and provide a
 * mechanism for vendor modules to hook and extend functionality
 */

struct task_struct;

DECLARE_HOOK(android_vh_sched_exit,
             TP_PROTO(struct task_struct *p),
             TP_ARGS(p));

#endif /* _TRACE_HOOK_SCHED_H */

/* This part must be outside protection */
#include <trace/define_trace.h>

כדי ליצור את הממשקים הנדרשים ל-hook של הספק, מוסיפים את קובץ הכותרת עם הצהרת ה-hook אל drivers/android/vendor_hooks.c ומיצאים את הסמלים. לדוגמה, הקוד הבא משלים את ההצהרה על ה-hook של android_vh_sched_exit().

#ifndef __GENKSYMS__
/* struct task_struct */
#include <linux/sched.h>
#endif

#define CREATE_TRACE_POINTS
#include <trace/hooks/vendor_hooks.h>
#include <trace/hooks/exit.h>
/*
 * Export tracepoints that act as a bare tracehook (i.e. have no trace
 * event associated with them) to allow external modules to probe
 * them.
 */
EXPORT_TRACEPOINT_SYMBOL_GPL(android_vh_sched_exit);

הערה: צריך להגדיר באופן מלא את מבני הנתונים שבהם נעשה שימוש בהצהרת ה-hook כדי להבטיח יציבות של ABI. אחרת היא לא בטוחה ל להסיט את המצביעים האטומים או להשתמש ב-build בהקשרים בגודל. הקטע include שמספק את ההגדרה המלאה של מבני הנתונים האלה צריך להופיע בקטע #ifndef __GENKSYMS__ של drivers/android/vendor_hooks.c. קובצי הכותרות ב-include/trace/hooks לא צריכים לכלול את קובץ הכותרת של הליבה עם הגדרות הטיפוסים, כדי למנוע שינויים ב-CRC שגורמים לשיבושים ב-KMI. במקום זאת, אני רוצה להעביר הם מצהירים על הסוגים.

צירוף להוקים (hooks) של ספקים

כדי להשתמש ב-hooks של ספקים, מודול הספק צריך לרשום טיפול ל-hook (בדרך כלל במהלך האינטוליזציה של המודול). לדוגמה, הקוד הבא מציג את הטיפול במודול foo.ko עבור trace_android_vh_sched_exit().

#include <trace/hooks/sched.h>
...
static void foo_sched_exit_handler(void *data, struct task_struct *p)
{
    foo_do_exit_accounting(p);
}
...
static int foo_probe(..)
{
    ...
    rc = register_trace_android_vh_sched_exit(foo_sched_exit_handler, NULL);
    ...
}

שימוש ב-hooks של ספק מקובצי הכותרת

כדי להשתמש בהוקים (hooks) של ספק מקובצי כותרת, יכול להיות שיהיה עליך לעדכן את ההוק (hook) של הספק קובץ כותרת כדי לבטל את ההגדרה של TRACE_INCLUDE_PATH כדי להימנע משגיאות build שמציינות לא נמצא קובץ כותרת של נקודת מעקב. לדוגמה,

In file included from .../common/init/main.c:111:
In file included from .../common/include/trace/events/initcall.h:74:
.../common/include/trace/define_trace.h:95:10: fatal error: 'trace/hooks/initcall.h' file not found
   95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../common/include/trace/define_trace.h:90:32: note: expanded from macro 'TRACE_INCLUDE'
   90 | # define TRACE_INCLUDE(system) __TRACE_INCLUDE(system)
      |                                ^~~~~~~~~~~~~~~~~~~~~~~
.../common/include/trace/define_trace.h:87:34: note: expanded from macro '__TRACE_INCLUDE'
   87 | # define __TRACE_INCLUDE(system) __stringify(TRACE_INCLUDE_PATH/system.h)
      |                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../common/include/linux/stringify.h:10:27: note: expanded from macro '__stringify'
   10 | #define __stringify(x...)       __stringify_1(x)
      |                                 ^~~~~~~~~~~~~~~~
.../common/include/linux/stringify.h:9:29: note: expanded from macro '__stringify_1'
    9 | #define __stringify_1(x...)     #x
      |                                 ^~
<scratch space>:14:1: note: expanded from here
   14 | "trace/hooks/initcall.h"
      | ^~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

כדי לתקן את סוג השגיאה הזה ב-build, צריך להחיל את התיקון המקביל על קובץ הכותרת של ה-hook של הספק שאתם כוללים. מידע נוסף זמין בכתובת https://r.android.com/3066703.

diff --git a/include/trace/hooks/mm.h b/include/trace/hooks/mm.h
index bc6de7e53d66..039926f7701d 100644
--- a/include/trace/hooks/mm.h
+++ b/include/trace/hooks/mm.h
@@ -2,7 +2,10 @@
 #undef TRACE_SYSTEM
 #define TRACE_SYSTEM mm

+#ifdef CREATE_TRACE_POINTS
 #define TRACE_INCLUDE_PATH trace/hooks
+#define UNDEF_TRACE_INCLUDE_PATH
+#endif

הגדרת UNDEF_TRACE_INCLUDE_PATH מורה ל-include/trace/define_trace.h לבטל את ההגדרה של TRACE_INCLUDE_PATH אחרי יצירת נקודות המעקב.

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

אם אף אחת מהשיטות הקודמות לא מאפשרת לכם להטמיע תכונה ממארז, עליכם להוסיף את התכונה כשינוי ספציפי ל-Android לליבה של הליבה. כדי להתחיל את השיחה, צריך ליצור בעיה בכלי למעקב אחרי בעיות (IT).

ממשק תכנות של משתמש באפליקציה (UAPI)

  • קובצי כותרות של UAPI שינויים ב- קובצי כותרות של UAPI חייבים להתרחש ב-upstream, אלא אם השינויים הם בממשקים ספציפיים ל-Android. שימוש בקובצי כותרות ספציפיים לספק כדי להגדיר ממשקים בין המודולים של הספק לבין קוד מרחב המשתמשים של הספק.
  • צמתים sysfs. לא להוסיף צומתי sysfs חדשים לליבה (kernel) של GKI (תוספות כאלה) תקפים רק במודולים של ספקים). צומתי sysfs שמשמשים את ה-SoC- ספריות שמתחלקות בין מכשירים שונים וקוד Java שמורכב מ-framework של Android ניתן לשנות רק בדרכים תואמות, וצריך לשנות אותם ב-upstream אם הם לא צומתי sysfs ספציפיים ל-Android. אפשר ליצור צמתים sysfs ספציפיים לספק לשימוש במרחב המשתמש של הספק. כברירת מחדל, הגישה לצומתי sysfs על ידי מרחב משתמשים נדחית באמצעות SELinux. על הספק להוסיף את תוויות SELinux המתאימות כדי לאפשר גישה לתוכנה מורשית של הספק.
  • צמתים של DebugFS מודולים של ספקים יכולים להגדיר צמתים ב-debugfs לצורך ניפוי באגים בלבד (כי debugfs לא מותקן במהלך הפעולה הרגילה של המכשיר).