לאחרונה ראיינו את eng.stk, המפתחת של ליבת blu_spark. בחלק זה אנו שואלים אותו על מקורותיו ועבודת הפיתוח שלו.
לאחרונה קיבלתי הזדמנות לראיין חבר בכיר ב-XDA eng.stk, מפתח של ליבת blu_spark. הוא זמין במכשירים רבים בפורומים שלנו, כולל ה-Nexus 5, OnePlus 3/T וה-OnePlus 5T. בחלק זה, אנו שואלים את eng.stk על מקורותיו בפיתוח וכיצד הוא מפתח את ליבת blu_spark.
אז ראשית, הצג את עצמך ואת הגרעין שלך. איך הקרנל שלך מבדיל את עצמו מהמתחרים? מהי פילוסופיית העיצוב שלך לשינויים בקרנל, ואיך אתה מבצע אותם?
אני eng.stk ואני קיים ב-XDA מאז 2010. רובכם מכירים אותי מפרויקטי code_blue ו-blu_spark שלי :)
התחלתי ב-XDA בכתיבת כמה סקריפטים וכלים שונים, פריצות למסגרת. עשיתי גם הרבה עיצובים... במהלך התקופה שלי כאן גם שיתפתי פעולה ישירות בכמה פרויקטים כמו Purity ROM, Universal Kernel Manager, Kernel Adiutor ולאחרונה Magisk ו WireGuard רק למנות כמה. עבדתי לאחרונה גם ב-TWRP (במיוחד במכשירי OnePlus), מודולי Magisk וכלים/פריצות אחרים [שהם] שימושיים במהלך מחזור החיים של פרויקטי הליבה שלי (כמה דברים הופיעו בפורטל XDA אם אני זוכר נכונה). ליבת blu_spark התחילה להפוך לא רק לקרנל, אלא לחוויה כוללת בין קרנל, שרשרת כלים, שחזור, עיצוב, כלים, סקריפטים וכו'. אבל עבודת הקרנל היא הדבר שאני הכי נהנה ממנו ומה שמניע אותי.
תמיד נהניתי לפרוץ ולבנות כמה קוד/סקריפטים כשהיתה לי ההזדמנות (לפרק צעצועים אלקטרוניים וקידוד בסיסי בקומודור 64 של בן דוד שלי היה כיף). עבורי קידוד אינו אמצעי להשגת מטרה אלא רק כלי כמו אחרים להשגת מטרה מוגדרת. רוב הדברים הרציניים יותר והיסודות של עבודתי נעשו כשגיליתי את לינוקס במהלך גיל ההתבגרות/שנות העשרים המוקדמות שלי. מאוחר יותר, אי שם בתקופת האוניברסיטה, אנדרואיד היה הצעד הבא ההגיוני עבורי: באמת חלום של מתעסק, שבו אפשר לשחק הרבה בחומרה או בתוכנה.
המילים הטובות ביותר לתיאור blu_spark הן אופטימיזציה ויציבות. אנשים שמשתמשים בו יודעים שהם יכולים לסמוך עליו. בניית הליבה שלי היא קצת 'מלאי' באופן שאני נוטה לא להסיר חלק מהדברים הזמינים מהקופסה, ולהשאיר הכל אופציונלי כדי שאנשים יוכלו לבחור. אני לא אוהב להוסיף יותר מדי דברים, אני פשוט משנה או מוסיף את מה שנראה לי הכי טוב עבור כל תחום נתון. מנהל ההתקן של תדירות ה-CPU, מתזמן ה-IO, פרוטוקולי הרשת, מערכות הקבצים וכו' או כוונון של כמה כוונונים עבור פרמטרים מסוימים או במעלה הזרם של כמה מנהלי התקנים עבור התוצאה הטובה ביותר האפשרית. אני גם בונה רשתות כלים בהתאמה אישית (מ-Linaro, טייק מדהים של GCC), בעיקר כדי להפיק את המיטב מהארכיטקטורה.
בשורה התחתונה, רוב האנשים יודעים שהם ב-blu_spark מהרגע שהם מבזיקים את הקרנל במכשיר. אני תמיד מחפש דברים חדשים ודרכים לתת את ה-UX הטוב ביותר שאפשר. בבטחה.
ספר לנו על המושל שלך ב-blu_active! מה זה, מה זה עושה ולמה זה מיוחד?
אני יודע שאנשים לפעמים מבלבלים בין blu_active לבין blu_spark. blu_active הוא רק חלק קטן בהשוואה לכל שאר [העבודה] שאני עושה.
מושל המעבד מקבל בעצם החלטות לגרום לתדרי המעבד לעלות או לרדת, בהתאם לצרכי המערכת. למושל היו כמה שינויים ומוטציות מאז תחילתו. כמו כל דבר אחר שאני עושה, הייתי צריך משהו שימלא את הצרכים שלי. זה מבוסס על המושל האהוב עלי, המושל האינטראקטיבי. בהתחלה פשוט שמתי עליו כמה דברים במעלה הזרם, אבל אז התחלתי להוסיף כמה דברים אחרים, כמו עדכוני CAF או היגיון שראיתי אצל מושלים אחרים שלדעתי שימושיים. הוספתי גם תאימות HMP ועוד כמה דברים טובים.
האיטרציה האחרונה מבוססת על ענף לינוקס 4.4 אנדרואיד של גוגל, עם כמה תיקונים במעלה הזרם ותיקוני CAF, אבל הרבה יותר רזה מבעבר. פשוט השתמש במה שיש לך במלואו, הסר את מה שאין לך. אני תמיד מנסה להשיג סוללה טובה יותר מאשר עם הגדרות מלאי, להפחית את הניקוז, תוך ניסיון לשפר ביצועים (ביצועים בחיים האמיתיים, זה שאתה מרגיש בעיניים ובאצבעות, לא עם סינטטי כלים).
בנקודת זמן מסויימת, רציתי מכוונן פשוט כדי שאנשים יוכלו לשחק עם הביצועים בצורה פשוטה. כך נולד פאסטליין :). ההיגיון דומה במקצת לאופן שבו פועלת הונדה VTEC: שחקו עם תזמונים מסף נתון. לכן, עם מתג פשוט וערך סף משתנה, אנשים יכולים לקבל קנה מידה ישיר ואגרסיבי יותר של תדרי המעבד. לגרום לו להיכנס במוקדם או במאוחר לפי עומס המערכת, עקיפת עומסי יעד. זה תואם לחלוטין ל-HMP וניתן להתאים אותו לכל אשכול בהתאם לצרכי האנשים, לכוונון עדין עבור כל מכשיר שהוא פועל עליו.
אילו מנגנונים או שינויים מובנים אתה אוהב/לא אוהב שיצרני OEM מספקים? כלומר חיזוק הקלט של קוואלקום.
חלק מההגדלות של מרחבי המשתמש וכוונונים אחרים המוגדרים ב-HALs (Hardware Abstraction Layers), חומרי מסגרת מקודדים וכו' יכולים לפעמים להיות מעצבנים. כמובן, ידוע שמפתחי ליבה עוקפים חלק מאלה. ב-Nexus 5, למשל, רובנו נפטרנו מ-mpdecision וקיבלנו Hotplug מותאם אישית - היה לנו blu_plug במקום באותו זמן. לחלק מהמכשירים האחרים היה ניהול תרמי גרוע ובקרה תרמית מותאמת אישית עם sysfs עבור רמות טמפ', תדירות הפחתת וכו'. לחלק מהמכשירים העדכניים יותר יש מדיניות קשיחה לגבי סוללה, ניתוק ליבות ודברים אחרים ב"רמות נמוכות" שלא הרוויחו ממשי בשימוש במכשיר. למען האמת, זה אפילו הרס לפעמים את חווית המשתמש, אז היה צורך לאלף את טכנולוגיות CTL ו-BCL.
אני גם זוכר שהסרתי הצפנה במכשירים כשזה היה עניין, כל השינויים שאיטרציות SELinux הציגו שינויים שגרמו לפריצות קודמות לעבוד בצורה אחרת... כמה שינויים אחרונים באבטחת אנדרואיד הם אתגר מתמיד. אלה כוללים AVB (חלקים מסוימים ידועים בעיקר כ-dm-verity). כמה שינויים אחרים הכניסו הגבלות למקומות tunables ו-sysfs שהיה צריך להעביר כי אין לנו גישה לאותם מקומות שהיו לנו קודם. רוב ההגבלות הללו רלוונטיות יותר ל-ROMs במלאי (בהם אני עושה את רוב העבודה שלי), בדרך כלל זה סולל את הדרך ומקל על ROMs מותאמים אישית (שם ההגבלות נמוכות יותר).
ב-SoCs אחרונים כמו Qualcomm Snapdragon 820 ו-835, כמה יצרני OEM הוסיפו כמה חיזוקים ממרחב המשתמש שמתקבלים בברכה ומתמודדים עם נקודות עיוורות במערכת, לא כל חומרי ה-OEM רעים. כשמדובר במקור ליבה, ככל שהמקור נקי ומתועד יותר, כך ייטב.
אילו תכונות נוספות אתה אוהב לכלול? כגון בקרת צבעים מתקדמת וכן הלאה.
בדרך כלל אני לא כולל דברים שאני לא משתמש בהם באופן אישי או שהם לא מועילים. דברים שאני אוהב לעשות, מלבד blu_active, כוללים אופטימיזציות ותיקונים של ארכיטקטורה, עדכוני דברים קריפטו, תזמון IO ועוד מוצרי אחסון/מערכת קבצים, KCAL, טעינה מהירה USB, חוזק רטט, בקרת LED סוללה/הודעות, חוסמי Wakelock, WireGuard, וכו ' אני תמיד בונה עם שרשרת כלים לבנייה מותאמת אישית כמו שאמרתי קודם.
באיזו מתודולוגיית בדיקה אתה משתמש עבור הליבה שלך? האם אתה משתמש בדוחות משתמשים, או בנצ'מרקים או בכל שגרה מותאמת אישית אחרת?
אני הבעלים של כל טלפון שאני מפתח עבורו, אז כל שינוי נבחן תמיד אני. מכיוון שאני נוהג מדי יום בכל מכשיר במשך תקופה ארוכה, כל דבר שאני מוצא לא מתאים לי, לא אמור להיות מתאים לאף אחד אחר. כשאני משחרר בפומבי מבנה, הוא כבר עבר המון בדיקות ממני ומכמה אנשים אחרים שאני סומך עליהם שיספקו משוב שימושי. אני יודע שלפעמים חלק מהמשתמשים משתעממים מכך שכל הדברים עובדים כמו שצריך, אבל אני מעריך יציבות מעל הכל: אני תמיד שם את עצמי על הנעליים של משתמש מלכתחילה.
אני מנהל את הדברים לקראת מקרה שימוש בחיים האמיתיים, לא בדיקות סינתטיות. תוכנה מסוג זה מיועדת לבני אדם, לא למכונות במשרד אחורי. נקודת ההתחלה תמיד טובה יותר מניסיון במניות, בכל החזיתות, אבל אני לא ממש מעריך את הציון הגבוה האחרון של Antutu כל כך. ניתן לכוון את הגרעינים שלי לסוג זה של אמת מידה, אבל זו לא המטרה הסופית שלי. אני כן מעריך כמה מדדים ישירים יותר, כמו בדיקות אחסון IO למשל. הם יכולים לתת דרך מהירה לטעון כמה שינויים שנעשו לאחרונה, למשל.
אני עושה את הבדיקות שלי עם רומי מלאי כדי שיהיה לי קו בסיס יציב לדברים. אני עושה בנייה מותאמות אישית עבור ROMs מותאמים אישית, אבל בגלל האופי הפכפך של ROMs מותאמים אישית עם תוספות נוספות, לילי ואפילו הבדל ביישום בחלק מהתכונות, אי אפשר לכסות את כולם ולתת תמיכה נאותה לכולם, לצערי.
לפעמים אני גם בונה גרסאות בטא כדי לבדוק משהו ספציפי או כשאני משיק גרסאות בטא ROMs או תצוגות מקדימות למפתחים. עשיתי את זה במכשירי Nexus ו-OnePlus, אנשים אוהבים לפעמים לבדוק דברים :)
בדוק את חלק 2: F2FS, EAS וטיפים למפתחי ליבה שואפים