לעבר אסטרטגיה חדשה בעיצוב מערכות הפעלה

(jpeg 10k)

מאמר זה מסביר מדוע FSF מפתחת מערכת הפעלה חדשה בשם הHurd, שתהיה היסוד של מערכת גנו כולה. הHurd בנוי על גבי הקרנל Mach 3.0 של CMU ומשתמש בניהול הזכרון הוירטואלי ובכלי העברת ההודעות של Mach. ספריית הC של גנו תספק את ממשק קריאות המערכת של יוניקס, ותקרא לHurd בשביל שירותים נדרשים שהיא לא יכולה לספק בעצמה. העיצוב והיישום של הHurd מובלים על ידי מייקל בושנל, עם עזרה מריצ'ארד סטולמן, רולאנד מקגארת', יאן בריטנסון ואחרים.

חלק 1: גישה שימושית יותר לעיצוב מערכות הפעלה

המטרה הבסיסית של מערכת הפעלה (OS) היא לאפשר למגוון תוכנות לחלוק מחשב יחיד ביעילות ובצורה יצרנית. דבר הדורש הגנה על זכרון, חלוקת זמן מתוזמנת עם זכות קדימה (preemptive), גישה מתואמת להתקני I/O, ושירותים אחרים. בנוסף מערכת הפעלה יכולה להרשות למספר משתמשים לחלוק מחשב. במקרה הזה, יעילות דורשת שירותים שמגינים על משתמשים מפגיעה אחד בשני, מאפשרים לשתף ללא הכנות מוקדמות, ומתווכים בגישה להתקנים פיזיים.

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

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

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

מספר מערכות ניסו להתגבר על הקשיים האלו. Smalltalk-80 ומכונת הLisp ייצגו שתיהן שיטה אחת לעקוף את הבעיה. קוד מערכת אינו שונה מקוד משתמש; כל המערכת נגישה למשתמש ויכולה להשתנות לפי הצורך. שתי המערכות נבנו סביב שפות שהקלו בביצוע החלפות והרחבות שכאלה. והצליחו במידה בינונית. אך שתיהן היו די עלובות בבידוד משתמשים ותוכנות אחד מן השני, ובכך נכשלו בהשגת אחת מהמטרות העיקריות העיצוב מערכת הפעלה.

פרוייקטים רבים שמשתמשים בקרנל Mach3.0 ממשיכים את המסורת הקשה לשינוי של עיצוב מערכות הפעלה. המבנה הפנימי שונה, אך נשאר אותו מחסום כבד בין משתמש למערכת. החד-שרתים (single-servers), למרות שהם הקלים ביותר לבניה, יורשים את קל הפגמים מהקרנלים המונוליטיים.

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

הGNU Hurd, בניגוד לכך, מעוצב כך שבאיזור של קוד המערכת יהיה מוגבל ככל האפשר. תוכנות נדרשות לתקשר רק עם מעט חלקים חיוניים של הקרנל; שאר המערכת ניתנת להחלפה בצורה דינמית. משתמשים יכולים להשתמש בכל חלק של שאר המערכת שהם רוצים, ויכולים בקלות להוסיף בעצמם מרכיבים שמשתמשים אחרים יוכלו לנצל. לא צריך להתקיים מראש אמון הדדי בשביל שמשתמשים ישתמשו בשירותים אחד של השני, והמערכת לא צריכה להפוך לפגיעה כתוצאה מכך שתבטח בשירותים של משתמשים ללא סינון.

זה נעשה על ידי זיהוי מרכיבי המערכת שמשתמשים חייבים להשתמש בהם כדי לתקשר אחד עם השני. אחד מהם אחראי לזיהוי זהות המשתמשים ונקרא שרת האותנטיקציה (authentication server). כדי לקבוע את הזהות אחת של השניה, תוכנות חייבות לתקשר, כל אחת עם שרת האותנטיקציה בו היא בוטחת. מרכיב אחר קובע את השליטה על מרכיבי מערכת על ידי משתמש-העל (superuser), ומספק פעולות פנקסנות. הוא נקרא שרת התהליכים (process server).

לא כל תובנות נמשתמש צריכות לתקשר עם שרת התהליכים; זה נחוץ רק לתכניות שדורשות את השירותים שלו. באותה מידה, שרת האותנטיקציה נחוץ רק בשביל תוכנות שרוצות לגלות את זהותן לאחרות. אף אחד מהשירותים הנותרים אינו בעל מעמד מיוחד; לא יישום הרשת, לא מערכת הקבצים, לא מנגנון הרצת התכניות (כולל setuid), ולא אף אחד אחר.

מנגנון המתרגם (Translator)

הHurd משתמש בפורטים של Mach בעיקר כאמצעי לתקשורת בין משתמשים ושרתים. (פורט של Mach הוא נקודת תקשורת במשימה (task) של Mach שם הודעות נשלחות ומתקבלות.) כל פורט מממש סדרה מסויימת של פרוטוקולים, שמייצגים פעולות שיכולות להיעשות באובייקט הנסתר שמיוצג על ידי הפורט. חלק מהפרוטוקולים שמוגדרים על ידי הHurd הם פרוטוקולי I/O, שמשמשים לפעולות I/O כלליות; פרוטוקול הקבצים, שמשמש לפעולות במערכת הקבצים; פרוטוקול הsocket שמשמש לפעולות רשת; ופרוטוקול התהליכים, שמשמש לשליטה בתהליכים וכו'

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

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

במנגנון הזה משתמשים בשביל mount על ידי זה שיש מתרגם שמקושר עם כל נקודת חיבור (mount point). כשתוכנה פותחת את נקודת החיבור, המתרגם (במקרה הזה, תוכנה שמבינה את מבנה הדיסק של מערכת הקבצים המחוברת) מורץ ומחזיר פורט לתוכנה. אחרי שהותחל המתרגם, אין להריץ אותו אלא אם הוא מת; מערכת הקבצים ההורה שומרת פורט למתרגם לשימוש בבקשות עתידיות.

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

שיטה אחת להשתמש במתרגמים היא לגשת למידע שמסודר בצורה הירארכית תוך שימוש בפרוטוקול הקבצים. לדוגמה, כל הסיבוכיות של ממשק המשתמש לתוכנה ftp נעלמת. משתמשים צריכים רק לדעת שתיקיה מסויימת מייצגת ftp ויכולים להשתמש בכל פקודות השליטה בקבצים (כמו ls או cp) כדי לגשת למערכת המרוחקת, במקום ללמוד סט חדש. באותה מידה מתרגם פשוט יכול להקל על הסיבוך בtar ו gzip. (גישה שקופה כזו תגבה מחיר נוסף, אך זה יהיה נוח).

שירותים כלליים

עם מתרגמים, יכולה מערכת הקבצים לתפקד כמפגש ממשקים שאינם זהים לקבצים. חשבו על שירות שמממש גירסה מסויימת של פרוטוקול X, ומשתמש בהודעות של Mach כאמצעי העברה בסיסי. לכל תצוגת X יכול להווצר קובץ עם התוכנה המתאימה בתור מתרגם. לקוחות של X יפתחו את הקובץ הזה. בנקודה זו מעט פעולות של קבצים יהיו שימושיות (קריאה וכתיבה, למשל, יהיו חסרות משמעות), אך פעולות חדשות (XcreateWindow או XDrawText) יכולות להפוך לבעלות משמעות. במקרה הזה פרוטוקול מערכת הקבצים מנוצל רק כדי לשלוט במאפיינים של העצם שמשמש כנקודת המפגש.

טכניקת המתרגם משמשת להתקשרות עם רוב השירותים בHurd שאינם בנויים כמערכות קבצים הירארכיות. לדוגמה, התקשורת עם שרת הסיסמאות, שמעניק תגי אישור בתמורה לסיסמאות, נעשית בדרך זו. גם עם שרתים של פרוטוקולי רשת מתקשרים בדרך זו. רולאנד מקגארת' חשב על שימוש זה במתרגמים.

תמונות חכמות של מערכת הקבצים

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

לHurd יהיה מתרגם שיוצר תיקיה שהיא איחוד תפיסתי של תיקיות אחרות, עם חוקים מסוגים שונים לפתרון בעיות התנגשות. זה יכול לעזור בהצגת תיקיה אחת למשתמשים, שמכילה את כל התוכנות שהם רוצים להריץ. ישנן גם גרסאות אחרות על בסיס הרעיון הזה.

מה המשתמש יכול לעשות

אף מתרגם לא מקבל הרשאות מעבר למקובל מעצם כך שהוא מחובר למערכת הקבצים. מתרגמים רצים עם עם הuid של הבעלים של הקובץ שהם מתרגמים, ורק אותם בעלים יכולים לכוון או לשנות אותם. הפרוטוקולים של הI/O ושל מערכת הקבצים עוצבו בזהירות כך שיתאפשר שימוש בהם על ידי שרתים ולקוחות שאין ביניהם אמון הדדי. מתרגמים הם סך הכל תוכנות רגילות. בספריית הC של גנו יש מגוון כלים שמקלים בכתיבת סוגים נפוצים של מתרגמים.

ישנם מתרגמים שדורשים הרשאות מיוחדות, כמו שרת הסיסמאות או מתרגמים שמאפשרים הרצת setuid. את המתרגמים הללו כל אחד יכול להריץ, אך רק אם הם מכוונים לעצם שבעליו הוא הroot הם יוכלו לספק את כל השירותים שלהם בהצלחה. זה מקביל למקרה בו כל משתמש יכול לקרוא לקריאת המערכת reboot, אבל היא תבוצע רק אם המשתמש הוא root.

למה זה כל כך שונה

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

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

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

חלק 2: מבט על כמה מהחיות בHurd

שרת האותנטיקציה

שרת האותנטיקציה הוא אחד מהשרתים היותר מרכזיים בHurd. כל פורט לשרת הזה מזהה משתמש והשרת מזהה אותו עם בלוק מזהה (id block). כל בלוק מזהה מכיל סדרה של מזהי קבוצה ומזהי משתמש. כל סדרה יכולה להיות ריקה. השרת הזה אינו דומה לשרת הססמאות שמוזכר לעיל.

שרת האותנטיקציה מייצא שלושה שירותים. ראשית, הוא מספק פעולות בוליאניות פשוטות על פורטים של אותנטיקציה: בהינתן שני פורטים של אותנטיקציה, השרת יספק פורט שלישי שמייצג איחוד של שני הסטים של מזהי קבוצה ומזהי משתמש. שנית, השרת מאפשר לכל משתמש עם uid (מזהה משתמש) אפס ליצור פורט אותנטיקציה כרצונו. לבסוף, השרת מספק RPCs (Remote Procedure Calls - קריאות פרוצדורה מרוחקות בין תכניות שונות ויתכן שגם בין מחשבים שונים) שמאפשרות ללקוחות שאין ביניהם אמון הדדי לקבוע את הזהות שלהם ולהעביר מידע ראשוני אחד על השני. דבר זה חיוני לאבטחה של מערכת הקבצים ופרוטוקולי הI/O.

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

שרת התהליכים

שרת התהליכים פועל כמחסן לסיווג מידע. ישנם ארבעה שירותים עיקריים שנתמכים על ידי השרת הזה. ראשית, שרת התהליכים מפקח על המידע הכללי ברמת המחשב שהקרנל Mach לא מטפל בו. לדוגמה, הhostname, הhostuid, וגירסת המערכת מתוחזקים על ידי שרת התהליכים. שנית, השרת דואג להיבטי הPosix של קבוצות של תהליכים ושל sessions, ומסייע לתוכנות שרוצות להשתמש בתכונות של Posix.

שלישית, שרת התהליכים דואג למיפוי אחד-לאחד בין משימות של Mach לבין תהליכים של Hurd. לכל משימה ניתן pid (מזהה תהליך). תהליכים יכולים לרשום בשרת הזה פורט הודעות , שמאותו רגע ניתן יהי לתת אותו לכל תוכנה שמבקשת אותו. השרת אינו מנסה לשמור את פורטי ההודעות פרטיים, כך שמצפים מתוכנות משתמש לממש בעצמן כל סוג של אבטחה שהן צריכות. (ספריית הC של גנו מספקת פונקציות נוחות לכל זה.) תהליכים יכולים לגלות לתהליך שרת את ערכי ה'argv' וה'envp' הנוכחיים שלהם; אז יספק השרת, במקרה של בקשה, את אותם וקטורים של ארגומנטים ומשתני סביבה. זה עוזר לכתיבת תוכנות דמויות ps וגם מקל להחביא או לשנות את המידע הזה. אף אחת מהתכונות הללו אינה נדרשת. תכניות חופשיות להתעלם מכל זה ולעולם לא לרשום את עצמן בשרת התהליכים. אך עדיין יינתן להן pid.

ולבסוף, שרת התהליכים מיישם אוספים של תהליכים, באמצעותם אוספים מספר פורטי הודעות של תהליכים באותו זמן. בנוסף לכך ישנם כלים שמסוגלים לבצע המרה בין pids, פורטי שרת של תהליכים ופורטי משימות של Mach, מבלי לפגוע ברמת האבטחה של הפורטים המנוהלים.

חשוב להדגיש ששרת התהליכים הוא אופציונלי. בגלל הגבלות בMach, תכניות חייבות לרוץ כroot כדי לזהות את כל המשימות במערכת. אך בהתחשב בזה, מספר שרתי תהליכים יכלו להתקיים בו זמנית, כל אחד עם הלקוחות שלו, כשכל אחד נותן מודל משלו של העולם. התכונות של שרת התהליכים שאינן דורשות הרשאות root ליישומן, יכולות להיבנות כשרתים צמודי-משתמש (per-user servers). ידיו של המשתמש אינן כבולות.

FTP שקוף

FTP שקוף הוא רעיון מעניין שזמנו הגיע. החבילה הפופולארית ange-ftp שזמינה לGNU Emacs הופכת את הגישה לקבצי FTP לשקופה לכאורה לכל פעולות השליטה על קבצים של Emacs. FTP שקוף עושה את אותו הדבר, רק באופן גורף. השרת עדיין איננו כתוב; הפרטים עדיין צריכים להבנות, והם בוודאי ישתנו כשנרויח קצת יותר נסיון.

בקרנל של BSD מערכת קבצים של FTP שקוף היא קלה לכתיבה בדיוק כמו בHurd. אבל אם תזכיר את הרעיון באוזני האקר של הקרנל של BSD, תקבל תגובה בנוסח "דבר כזה לא שייך לקרנל". במובן מסויים זה נכון. הכנסת דבר כזה לקרנל  מפרה את כל העקרונות של מבנה השכבות במערכות מסוג זה. אולם תופעת הלוואי העגומה היא שמתודולוגיית עיצוב (שבבסיסה מניעת משתמשים מן היכולת לשנות דברים שהם לא אוהבים) משמשת למנוע ממעצבי מערכות אפשרות לשפר דברים. (לאחרונה קרנלים של BSD מאפשרים לכתוב תוכנת משתמש שמספקת FTP שקוף. לדוגמה alex, אבל זה דורש הרצה עם הרשאות root מלאות.

בHurd אין מכשולים בפני בניית FTP שקוף. מתרגם יסופק לעצם ftp/. התוכן של ftp/ בוודאי לא יהיה ניתן לרישום ישירות, למרות שתת-תיקיות מתחתיו כן יהיו. יהיה מגוון של פורמטים אפשריים. לדוגמה, בשביל לגשת לקבצים בuunet, יהיה אפשר לבצע cd /ftp/ftp.uu.net:anonimous:mib@gnu. או בשביל לגשת לקבצים בחשבון משתמש מרוחק, יהיה ניתן להריץ cd /ftp/gnu.org:mib:passwd. יהיה אפשר להשמיט חלקים מן הפקודה, ותוכנת הFTP השקוף תקרא אותם מן הקובץ .netrc של המשתמש. במקרה הזה יהיה אפשרי לבצע פשוט cd /ftp/gnu.org; כששאר הנתונים נמצאים כבר ב.netrc.

אין צורך לבצע קודם cd -- אפשר להשתמש בכל פקודה של קבצים. כדי ללמוד על RFC 1097 (Telnet subliminal message option), אפשר פשוט להריץ more /ftp/ftp.uu.net/inet/rfc/rfc1097. ניתן להשתמש בפקודת העתקה לדיסק מקומי אם רוצים לקרוא את הRFC לעיתים קרובות.

מערכות קבצים

נעשה גם מימוש של מערכות קבצים רגילות. גרסת השחרור הראשונית של הHurd תכיל מערכת קבצים עם תאימות לאחור לBSD 4.4 Fast File System. בנוסף לעולם מושגים הרגיל, היא תספק אמצעים לשמור מתרגמים, תציע מזהי קבוצה ומזהי משתמש של 32 ביט, ותספק מזהה חדש לכל קובץ שייקרא היוצר של הקובץ, שהבעלים של הקובץ יוכל לשים בו ערך כרצונו. בנוסף, בגלל שלמשתמשים בHurd יוכלו להיות מספר uids (אפילו אפס), ישנו סט נוסף של ביטים של הרשאות שמספק בקרת גישה למשתמש לא ידוע (אפס uids) בניגוד למשתמש ידוע אבל לא מסוים (מספר uids: הקטגוריה הקיימת world של השראות קובץ).

פרוטוקול Network File System ימומש באמצעות 4.4 BSD בתור התחלה. תמומש גם מערכת קבצים במבנה לוג תוך שימוש באותם רעיונות שיושמו בSprite, אך כנראה לא באותו פורמט. ייתכן שנספיק להגדיר פרוטוקול קבצים רשתי של גנו, או ש.NFS יורחב כדי לסלק את הפדמים שבו. יהיו גם כל מיני מערכות קבצים "קטנות", כמו מערכת הקבצים של MS-DOS, כדי לעזור לאנשים להעביר קבצים בין גנו ומערכות קבצים אחרות.

מסופים

שרת I/O יספק למסוף מושגים של Posix. לספריית הC של גנו יש תכונות למעקב אחרי המסוף השולט ולארגון הדברים כך שהסיגנלים הנכונים של שליטה בג'ובים יישלחו בזמנים הנכונים, כמו גם תכונות לתגובה למקלדת ולסיגנלים של התקעות.

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

אין שום דבר בדרייבר של המסוף שנכפה על המשתמשים. דרייבר של מסוף מאפשר למשתמש להשיג בקלות את ערוץ התקשורת שבבסיסו, לעקוף אותו כשצריך או בכלל, או להחליף תוכנה דמויית דרייבר אחרת. במקרה האחרון שהוזכר, אם התוכנה החלופית מיישמת את הממשקים הנדרשים, ספריית הC תשתמש בה כאילו היא היתה הדרייבר הרגיל של המסוף.

עקב הגמישות הזו, הדרייבר המקורי של המסוף לא יספק תכונות עריכת שורה מסובכות, אלא יגביל את עצמו להתנהגות שמוגדרת בPosix ובBSD. בבוא הזמן יהיה דרייבר מסוף מבוסס readline, שיספק תכונות עריכת-שורה מסובכות למשתמשים שירצו זאת.

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

הרצת תוכנות

המימוש של הקריאה execve מתפרש על פני שלוש תוכנות. הספריה מסדרת את וקטורי הארגומנטים והסביבה. אז היא שולחת הודעה לשרת הקבצים שמחזיק את הקובץ שצריך להריץ. שרת הקבצים בודק את הרשאות ההרצה ומבצע את כל השינויים שנראים לו בקריאה exec. לדוגמה, אם הקובץ מסומן עם setuid ולשרת הקבצים יש את היכולת, הוא ישנה את זהות המשתמש של האימג' החדש. שרת הקבצים גם מחליט אם תוכנות שהיתה להן גישה למשימה הישנה ימשיכו לקבל גישה למשימה החדשה. אם שרת הקבצים מאריך תוקף של הרשאות, או מריץ אימג' בלתי קריא, אז התכנית המורצת צריכה להתקיים במשימת Mach חדשה כדי לשמור על רמת האבטחה.

אחרי שמחליטים על המדיניות שמקושרת עם האימג' החדש, מערכת הקבצים קוראת לשרת ההרצות (exec server) שיטען את המשימה. השרת, שמשתמש בספריית BFD (Binary File Descriptor) ,טוען את האימג'. BFD תומך במספר גדול של פורמטים של קבצי אובייקט; כמעט כל פורמט נתמך יהיה בר הרצה. השרת גם מטפל בסקריפטים שמתחילים ב !#, ומריץ אותם דרך התכנית המוגדרת.

שרת ההרצות הרגיל גם מסתכל בסביבה של האימג' החדש; אם היא מכילה משתנה שנקרא EXECSERVERS הוא משתמש בתכניות שמוגדרות שם כשרתי הרצה במקום בברירת המחדל של המערכת. (מה שכמובן לא נעשה עבור הרצות ששרת הקבצים הנ"ל ביקש לשמור מאובטחות)

האימג' החדש מתחיל לרוץ בספריית הC של גנו, ששולחת הודעה לשרת ההרצות להשיג את הארגומנטים, הסביבה, הumask, התיקיה הנוכחית, וכו'. אף אחת מההגדרות הנוספות הללו מיוחדת לקובץ או לשרת ההרצה; אם תוכנות רוצות, הן יכולות להשתמש ביכולת זו בצורה שונה מהספריה.

תהליכים חדשים

הקריאה fork ממומשת כמעט במלואה בספריית הC של גנו. המשימה החדשה נוצרת באמצעות קריאות קרנל של Mach. ספריית הC דואגת שהאימג' שלה יעבור בתורשה כמו שצריך. המשימה החדשה עוברת הרשמה בשרת התהליכים (למרות שאין חובה שזה יקרה). ספריית הC מספקת וקטורים של פונקציות שייקראו בזמן ההתפצלות: וקטור אחד שייקרא לפני ההתפצלות, אחד אחריה בהורה, ואחד אחריה בצאצא. (אין להשתמש בתכונות אלו במקום רצף הקריאה הרגיל לfork; הן נועדו לספריות שצריכות לסגור פורטים או לנקות את השטח לפני שמתרחשת התפצלות.) ספריית הC תיישם גם קריאות fork שמוגדרות בטיוטת Posix.4a (הצעת הסטנדרט שעוסקת בהרחבת threads להרחבת זמן-האמת).

שום דבר לא מכריח את המשתמש ליצור משימות חדשות בדרך זו. אם תוכנה רוצה להשתמש כמעט בfork הרגיל, רק עם כמה מאפיינים מיוחדים, היא יכולה לעשות זאת. Hooks יסופקו על ידי ספריית הC, או שהפונקציה יכולה אפילו להיות מוחלפת בשלמותה. שום דבר מאלה אינו אפשרי במערכת יוניקס מסורתית.

הודעות א-סינכרונית

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

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

גם לספריית הC יש הודעות להוספת ומחיקת uids שנמצאים בשימוש על ידי התהליך. אם uids חדשים נשלחים לתוכנה, הספריה מוסיפה אותם לסט הנוכחי שלה, ואז מחליפה הודעות עם כל שרתי הI/O שהיא יודעת עליהם, ובכך מאשרת להם את ההרשאות החדשות שלה. בצורה דומה, הודעה יכולה למחוק uids. במקרה שכזה, מי שקרא חייב לספק את פורט המשימה של התהליך. לדוגמה, הפקודה su תוכל לגרום לכל התוכנות בsession ההתחברות הנוכחי שלך לקבל uid חדש, במקום ליצור תת-shell חדשה.

ספריית הC תאפשר לתוכנות להוסיף הודעות א-סינכרוניות שהן רוצות לזהות, כמו גם למנוע הכרה של הסט הסטנדרטי.

לגרום לזה להיראות כמו יוניקס

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

בכמה סביבות תהיה תמיכה גם בתאימות בינארית. זה יעבוד באמצעות בניית גירסה מיוחדת של הספריה שתיטען אז איפה שהוא במרחב הכתובות של התהליך. (לדוגמה, על VAX היא תוכנס מעל המחסנית.) בשלב הזה ישתמשו בתכונה של Mach, שנקראת הכוונה מחדש של קריאות מערכת, כדי ללכוד קריאות מערכת של יוניקסולהפוך אותן לקפיצות לתוך הגירסה המיוחדת של הספריה. (כמעט בכל המכונות, המחיר של כוונון מחדש שכזה הוא קטן מאוד; זה נתיב שעבר אופטימיזציה חזקה מאוד בMach. ב386 זה בערך שני תריסר הוראות. שזה רק מעט יותר גרוע מקיאה רגילה לפרוצדורה.)

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

פרוטוקולי רשת

לHurd תהיה ספריה שתקל מאוד על הסבה של הprotocol stacks של 4.4 BSD לHurd. זה יאפשר הפעלה, לכאורה בחינם, של כל הפרוטוקולים שנתמכים על ידי BSD. נכון להיום זה כולל את הפרוטוקולים של CCITT, את פרוטוקולי TCP/IP, את פרוטוקולי NS של זירוקס, ואת הפרוטוקולים של ISO.

בשביל פעולה אופטימלית יהיה צורך בעבודה בשביל ניצול תכונות של הHurd שמספקות I/O במהירות גבוהה מאוד. בשביל רוב הפרוטוקולים זה ידרוש מעט מחשבה, אך לא יותר מדי זמן. הHurd יריץ את הפרוטוקולים של TCP/IP בצורה היעילה ביותר שאפשר.

דוגמה מעניינת לגמישות של עיצוב הHurd ניתן למצוא במקרה של גרורות IP (IP trailers), שנפוצות מאוד בשימוש בBSD. למרות שהHurd יסכים לשלוח ולקבל גרורות, הוא ירויח מעט מאוד מצורת הפעולה הזו בגלל שאין דרישה שהמידע יועתק והמנעות מעותקים בשביל מידע מיושר-על-פי-דף (page aligned) אינה רלוונטית.

חזור לדף הבית של גנו.

FSF & GNU inquiries & questions to gnu@gnu.org. Other ways to contact the FSF.

Comments on these web pages to webmasters@www.gnu.org, send other questions to gnu@gnu.org.