מפתחים מגוגל הציעו לפתח libc משלהם עבור LLVM

אחד המפתחים מגוגל מוּרָם ברשימת התפוצה של LLVM אודות פיתוח ספריית C סטנדרטית מרובת פלטפורמות (Libc) במסגרת פרויקט LLVM. מכמה סיבות, גוגל לא מסתפקת ב-libc הנוכחי (glibc, musl) והחברה בדרך לפיתוח מימוש חדש, שמוצע לפיתוח במסגרת LLVM.

פיתוחי LLVM שימשו לאחרונה כבסיס לבניית כלי ההרכבה של גוגל. הרעיון המרכזי הוא שאם גוגל כבר התחילה לפתח את ה-libc שלה, אז למה לא לפתח מיד את המערכת שלה במסגרת LLVM, שכבר מציעה ספרייה סטנדרטית משלה עבור C++ (Libc++), אבל אין לה ספרייה סטנדרטית דומה עבור C (libc).

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

הפרויקט עדיין בשלב הפיתוח הראשוני, אך כבר הוגדרו מטרות בסיסיות:

• מודולריות ופיתוח בהתאם לפילוסופיה של אספקת ספרייה גרעינית ולא סט מונוליטי;
• תמיכה בקישור סטטי במצבים PIE (קובצי הפעלה בלתי תלויים במיקום) וללא PIE. מתן CRT (זמן ריצה C) ומטען PIE עבור קובצי הפעלה מקושרים סטטית;
• תמיכה ברוב הפונקציות הסטנדרטיות של ספריית C, עם תוספות POSIX וכמה הרחבות ספציפיות למערכת הנדרשות על ידי יישומים קיימים;
• היזהר עם הרחבות ספציפיות לספק והוסף אותן רק כאשר יש צורך. לגבי תמיכה בהרחבות של צד שלישי, מוצע להשתמש בגישה של הפרויקטים Clang ו-libc++;
• שימוש בשיטות עבודה מומלצות בפיתוח באמצעות ערכת הכלים של LLVM, כגון שימוש בחומר חיטוי ובדיקות מטושטש כבר מההתחלה.

אחד ממפתחי LLVM הפעילים הצביעברור שזה הגיוני לשלוח את libc כחלק מערך הכלים של LLVM, אבל בדרך כלל, כשמתעורר צורך כזה, הם משתמשים בספריית musl, שכתובה היטב, תומכת בארכיטקטורות שונות ומספקת את הפונקציונליות הדרושה, כולל תמיכה בדינמיות מְקַשֵׁר. יכול להיות שזה מוצדק להטמיע את musl לתוך LLVM ולפתח אותו כמזלג המסונכרן עם הפרויקט הראשי.

גם דעתך לידי ביטוי מחבר פרויקט Musl, שניסה לטעון מדוע ההצעה של גוגל והכללת Libc בהפצת LLVM הם רעיונות גרועים מאוד:

• פיתוח ותחזוקה של Libc נכון, תואם ואיכותי היא משימה קשה מאוד. הבעיה היא לא בכמות הקוד, אלא בהקפדה על התנהגות נכונה וקשיים ביישום ממשקים, תוך התחשבות בשכבת האפליקציות העצומה שנכתבו אי פעם ב-C/C++, וכן באפליקציות בשפות אחרות, שזמן הריצה שלהן נמצא בשימוש מאת Libc. גישה חזיתית מבלי לקחת בחשבון את הניואנסים רק תוביל לכך שהרבה תוכניות קיימות לא יוכלו לעבוד עם Libc, אבל אז פרויקט כזה לא יעניין את הצרכנים.
• פיתוח תאגידי יכול להרוס את Libc, אבל לדחוף אותו לשימוש נרחב, וכתוצאה מכך הצורך להוסיף פריצות כדי להבטיח תאימות באפליקציות. פיתוח בחסות פרויקט קוד פתוח תאגידי ימשוך את השמיכה לכיוון הצרכים והפתרונות של החברה, תוך פגיעה באינטרסים של הקהילה. לדוגמה, אם אתה מזהה בעיה שנגרמת על ידי באג בתוכנה אחרת, בפיתוח מבוקר קל יותר להבטיח ש-Libc תואם לבאג זה מאשר לתקן את הבאג עצמו. אפל משתמשת במזלג BSD libc למטרות אלו, וגוגל משתמשת במזלג המוסל בפוקסיה. הניסיון של מפתח musl הוא שפנו אליו בעיקר על ידי עורכי דין לבירור נושאי רישוי, אך מעולם לא פנו אליו לבירור פרטים טכניים לפני ביצוע שינויים חסרי תועלת ומפריעים בסניפיו.
• היעדר מונו-תרבות בפיתוח libc והתמקדות בסטנדרטים מונעי הסכמה ולא בשליטה אינדיבידואלית, מה שמניע מפתחי יישומים להשתמש בתקנים במקום להיות קשורים ליישומים ספציפיים. לכן מחבר ה-musl מתנגד להכללת ספרייתו ב-LLVM, וכן נגד פיתוח libc בתוך LLVM, שכן במקרה זה האופי העצמאי של libc אובד ויישום מסוים הופך לפתרון ממדרגה ראשונה עבור LLVM, וכל השאר הופכים לפתרון סוג ב'.

מקור: OpenNet.ru