דף זה תורגם על ידי Cloud Translation API.

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

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

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

התיקון נשלח ל-LKML, אבל לא התקבל בזמן להשקת מוצר. כדי לטפל בתיקון הזה:
- צריך לספק הוכחה לכך שהתיקון נשלח ל-LKML ולתגובות שהתקבלו בשביל התיקון, או מהו הזמן המשוער שבו התיקון נשלח ב-upstream.
- להחליט על דרך פעולה להטמעת התיקון ב-ACK, לקבל אישור למעלה בזרם (upstream) ואז להסיר אותו מ-ACK כשהגרסה הסופית של upstream תשולב ב-ACK.
התיקון מגדיר את EXPORT_SYMBOLS_GPL() למודול של ספק, אבל לא ניתן היה לשלוח אותו ל-upstream כי אין מודולים בעץ שמשתמשים בסמל הזה. כדי לטפל בתיקון הזה, עליך לספק פרטים על הסיבה לכך שלא ניתן לשלוח את המודול ל-upstream, ועל האפשרויות החלופיות שבדקת לפני שליחת הבקשה.
התיקון לא מספיק כללי כדי להשתמש בו ב-upstream, ואין זמן לבצע בו refactoring לפני השקת המוצר. כדי לטפל בתיקון הזה, עליך לציין מתי תשלחו תיקון שעבר רה-פירמנטציה ל-upstream (התיקון לא יתקבל ב-ACK בלי תוכנית לשליחת תיקון שעבר רה-פירמנטציה ל-upstream לבדיקה).
אי אפשר לקבל את התיקון ב-upstream כי… <insert reason here>. כדי לטפל בתיקון הזה, צריך לפנות לצוות הליבה של 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 חייבים לעמוד בסטנדרטים של קידוד הליבה של Linux ושל ההנחיות לתרומות. צריך לכלול תג Change-Id בהודעת השמירה. אם שולחים את התיקון לכמה הסתעפויות (למשל, android-mainline ו-android12-5.4), צריך להשתמש באותו Change-Id בכל המופעים של התיקון.

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

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

אחרי שתיקון מתקבל ב-upstream או ב-android-mainline, אפשר להעביר אותו לאחור אל ה-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: – סביר להניח שיתקבלו גם תיקונים מ-upstream שלא עוברים שינויים מדויקים וצריכים שינוי, אם יש תרחיש לדוגמה סביר.
FROMGIT: – תיקונים שנבחרו בקפידה מענף של מנהל תוכנה לקראת שליחה ל-Linux mainline עשויים להתקבל אם יש מועד הגשה קרוב. צריך להצדיק את הבקשות האלה גם לגבי התוכן וגם לגבי לוח הזמנים.
FROMLIST: – תיקונים שנשלחו ל-LKML אבל עדיין לא אושרו להוספה להסתעפות של המנהל, לא צפויים להתקבל, אלא אם ההצדקה מספיק משכנעת כדי שהתיקון יתקבל גם אם הוא לא ייכלל ב-Linux למקור (אנחנו מניחים שהוא לא ייכלל). כדי לאפשר דיון עם צוות הליבה של Android, צריכה להיות בעיה שקשורה לתיקוני FROMLIST.

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

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

שינויים ב-gki_defconfig

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

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

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

שינויים אחרים בקטגוריה הזו הם עדכונים בקובצי ייצוג של KMI, ברשימות סמלים של KMI, ב-gki_defconfig, בסקריפטים ל-build או בתצורה, או בסקריפטים אחרים שלא קיימים ב-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. למסגרות (כמו framework תרמי) שלא תומכות במנהלים או במנהלי התקנים שניתנים לטעינה אבל עדיין דורשים הטמעה ספציפית לספק, צריך ליצור בעיה ב-IT ולהתייעץ עם צוות הליבה של Android.

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

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

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

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

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

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

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

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

כדי למנוע התנגשויות פוטנציאליות בין שדות שנדרשים לספקים לבין שדות שנדרשים ליצרני ציוד מקורי (OEM), יצרני ציוד מקורי (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) של ספקים

כדי להוסיף ווקים של ספקים לקוד הליבה בתור נקודות מעקב, מכריזים עליהם באמצעות 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() בודקת בהתחלה רק אם משהו מצורף. אבל, אם מודול של ספק רושם handler באמצעות register_trace_android_vh_sched_exit(), הפונקציה הרשומה נקראת. הטיפול צריך להיות מודע להקשר לגבי מנעולים מוחזקים, מצב 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. אחרת, לא בטוח לבצע הסרה של הפניה (dereference) של ההפניות האטומות או להשתמש ב-struct בהקשרים עם גודל. הכללה שמספקת את ההגדרה המלאה של מבני נתונים כאלה צריכה להיכלל בקטע #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 של ספק מקובצי הכותרת

כדי להשתמש ב-vendor hooks מקובצי כותרות, יכול להיות שתצטרכו לעדכן את קובץ הכותרת של ה-vendor 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 לליבה של GKI (תוספות כאלה תקפות רק במודולים של ספקים). אפשר לשנות צמתים של sysfs שמשמשים את הספריות והקוד ב-Java שמרכיבים את מסגרת Android, שהם לא תלויים ב-SoC ובמכשיר, רק בדרכים תואמות, וצריך לשנות אותם ב-upstream אם הם לא צמתים ספציפיים ל-Android. אפשר ליצור צומתי sysfs ספציפיים לספק לשימוש במרחב המשתמשים של הספק. כברירת מחדל, הגישה ל-sysfs ממרחב המשתמשים נדחית באמצעות SELinux. הספק צריך להוסיף את תוויות ה-SELinux המתאימות כדי לאפשר גישה לתוכנות של ספק מורשה.
צמתים של DebugFS במודולים של ספקים אפשר להגדיר צמתים ב-debugfs לניפוי באגים בלבד (כי debugfs לא נטען במהלך פעולה רגילה של המכשיר).