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

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

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

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

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

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

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

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

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

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

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

שינויים ב-gki_defconfig

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

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

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

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

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

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

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

פקדים שניתנים לטעינה

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

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

קטעי הוק (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) מוגבלים של ספקים במקרים כמו קטעי הוק (hooks) לתזמון כאשר צריך לקרוא לפונקציה המצורפת גם אם המעבד (CPU) במצב אופליין או דורש הקשר לא אטומי. לא ניתן לנתק קטעי הוק (hooks) של ספקים מוגבלים, לכן מודולים שמחוברים להוק מוגבל אף פעם לא יכולים להסיר את הנתונים שנטענו. מוצר שהצפייה בו הוגבלה שמות ה-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() בודקת בהתחלה רק אם יש משהו מצורף. אבל, אם מודול ספק רושם handler באמצעות 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 ולייצא את סמלים. לדוגמה, הקוד הבא משלים את ההצהרה של תוכן הוק (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 בהקשרים בגודל. כוללים שמספק את ההגדרה המלאה של מבני נתונים כאלה, צריך להיכלל קטע #ifndef __GENKSYMS__ מתוך drivers/android/vendor_hooks.c. הכותרת קבצים ב-include/trace/hooks לא יכולים לכלול את קובץ כותרת הליבה (kernel) עם כדי להימנע משינויים ב-CRC שעלולים לשבור את ה-KMI. במקום זאת, אני רוצה להעביר הם מצהירים על הסוגים.

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

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

תכונות ליבה (kernel)

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

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

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