כיצד מיישמים צינורות ב-Unix

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

על מה זה?

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

$ echo hello | wc -c
6

פונקציונליות זו תלויה בקריאה למערכת המסופקת הליבה pipe, המתואר בדפי התיעוד צינור (7) и צינור (2):

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

הצינור נוצר באמצעות הקריאה pipe(2), המחזיר שני מתארי קבצים: האחד מתייחס לקלט של הצינור, השני לפלט.

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

$ strace -qf -e execve,pipe,dup2,read,write 
    sh -c 'echo hello | wc -c'

execve("/bin/sh", ["sh", "-c", "echo hello | wc -c"], …)
pipe([3, 4])                            = 0
[pid 2604795] dup2(4, 1)                = 1
[pid 2604795] write(1, "hellon", 6)    = 6
[pid 2604796] dup2(3, 0)                = 0
[pid 2604796] execve("/usr/bin/wc", ["wc", "-c"], …)
[pid 2604796] read(0, "hellon", 16384) = 6
[pid 2604796] write(1, "6n", 2)        = 2

תהליך ההורה קורא pipe()כדי לקבל מתארי קבצים רכובים. תהליך צאצא אחד כותב לידית אחת, ותהליך אחר קורא את אותם נתונים מנקודת אחיזה אחרת. המעטפת משתמשת ב-dup2 כדי "לשנות שם" לתיאורים 3 ו-4 כדי להתאים ל-stdin ו-stdout.

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

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

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

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

מה אנחנו מחפשים?

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

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

איפה אנחנו מחפשים?

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

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

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

אגב, pipe הוא שיחת מערכת מספר 42 בטבלה sysent[]. יָד הַמִקרֶה?

גרעיני יוניקס מסורתיים (1970–1974)

לא מצאתי עקבות pipe(2) גם לא ב PDP-7 Unix (ינואר 1970), ולא ב מהדורה ראשונה של יוניקס (נובמבר 1971), וגם לא בקוד המקור הלא שלם מהדורה שנייה (יוני 1972).

TUHS קובע זאת מהדורה שלישית של יוניקס (פברואר 1973) הפכה לגרסה הראשונה עם מסועים:

Unix 1973rd Edition הייתה הגרסה האחרונה עם ליבה שנכתבה בשפת assembly, אבל גם הגרסה הראשונה עם pipelines. במהלך XNUMX בוצעה עבודה לשיפור המהדורה השלישית, הקרנל שוכתב ב-C, וכך הופיעה המהדורה הרביעית של יוניקס.

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

בספרו של בריאן קרניגאןיוניקס: היסטוריה וזכרון"בהיסטוריה של הופעתם של מסועים, מוזכר גם המסמך הזה: "... הוא היה תלוי על הקיר במשרד שלי ב-Bell Labs במשך 30 שנה." כאן ראיון עם מקילרוי, ועוד סיפור מ עבודתו של מקילרוי, שנכתבה ב-2014:

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

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

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

יש לנו תיעוד טקסט עבור pipe(2) משתי הגרסאות, כך שתוכל להתחיל בחיפוש בתיעוד מהדורה שלישית (עבור מילים מסוימות, קו תחתון "ידנית", מחרוזת מילולית ^H, ואחריה קו תחתון!). הפרוטו הזה-pipe(2) כתוב בשפת assembly ומחזיר רק מתאר קובץ אחד, אבל כבר מספק את פונקציונליות הליבה הצפויה:

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

בשנה שלאחר מכן הגרעין נכתב מחדש ב-C, ו pipe(2) במהדורה הרביעית רכש את המראה המודרני שלו עם אב הטיפוס"pipe(fildes)»:

שיחת מערכת מקטרת יוצר מנגנון קלט/פלט הנקרא צינור. ניתן להשתמש בתיאורי הקובץ המוחזרים בפעולות קריאה וכתיבה. כאשר משהו נכתב לצינור, נעשה שימוש ב-handle המוחזרת ב-r1 (בהתאמה fildes[1]), מאגרת ל-4096 בתים של נתונים, ולאחר מכן תהליך הכתיבה מושעה. בעת קריאה מהצינור, הידית המוחזרת ל-r0 (בהתאמה fildes[0]) לוקחת את הנתונים.

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

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

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

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

המהדורה השישית של יוניקס (1975)

בואו נתחיל לקרוא את קוד המקור של יוניקס מהדורה שישית (מאי 1975). בעיקר בזכות אריות הרבה יותר קל למצוא אותו מאשר המקורות של גרסאות קודמות:

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

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

לפני יותר מ-15 שנה, הקלדתי עותק של קוד המקור המופיע ב אריות, כי לא אהבתי את האיכות של העותק שלי ממספר לא ידוע של עותקים אחרים. TUHS לא היה קיים עדיין ולא הייתה לי גישה למקורות הישנים. אבל בשנת 1988, מצאתי קלטת ישנה בת 9 רצועות שהכילה גיבוי ממחשב PDP11. היה קשה לדעת אם זה עובד, אבל היה עץ /usr/src/ שלם שבו רוב הקבצים סומנו עם שנת 1979, שכבר אז נראתה עתיקה. זו הייתה המהדורה השביעית או הנגזרת שלה PWB, כפי שהאמנתי.

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

והיום אנחנו יכולים לקרוא באינטרנט ב-TUHS את קוד המקור של המהדורה השישית מ ארכיון, שאליו הייתה יד לדניס ריצ'י.

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

בהתחלה /usr/sys/ken/pipe.c יש הערת הסבר (וכן, יש עוד /usr/sys/dmr):

/*
 * Max allowable buffering per pipe.
 * This is also the max size of the
 * file created to implement the pipe.
 * If this size is bigger than 4096,
 * pipes will be implemented in LARG
 * files, which is probably not good.
 */
#define    PIPSIZ    4096

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

באשר לקבצי LARG, הם תואמים דגל אינודה LARG, המשמש את "אלגוריתם הכתובות הגדול" לעיבוד בלוקים עקיפים לתמיכה במערכות קבצים גדולות יותר. מכיוון שקן אמר שעדיף לא להשתמש בהם, אני בשמחה אקבל את המילה שלו.

הנה קריאת המערכת האמיתית pipe:

/*
 * The sys-pipe entry.
 * Allocate an inode on the root device.
 * Allocate 2 file structures.
 * Put it all together with flags.
 */
pipe()
{
    register *ip, *rf, *wf;
    int r;

    ip = ialloc(rootdev);
    if(ip == NULL)
        return;
    rf = falloc();
    if(rf == NULL) {
        iput(ip);
        return;
    }
    r = u.u_ar0[R0];
    wf = falloc();
    if(wf == NULL) {
        rf->f_count = 0;
        u.u_ofile[r] = NULL;
        iput(ip);
        return;
    }
    u.u_ar0[R1] = u.u_ar0[R0]; /* wf's fd */
    u.u_ar0[R0] = r;           /* rf's fd */
    wf->f_flag = FWRITE|FPIPE;
    wf->f_inode = ip;
    rf->f_flag = FREAD|FPIPE;
    rf->f_inode = ip;
    ip->i_count = 2;
    ip->i_flag = IACC|IUPD;
    ip->i_mode = IALLOC;
}

התגובה מתארת ​​בבירור מה קורה כאן. אבל הבנת הקוד לא כל כך קלה, בין היתר בגלל הדרך"struct user u» ונרשם R0 и R1 פרמטרי קריאת מערכת וערכי החזרה מועברים.

בואו ננסה עם ialloc() לשים על דיסק inode (ידית אינדקס)ועל ידי falloc() - הצב שניים בזיכרון файла. אם הכל ילך כשורה, נגדיר דגלים לזהות את הקבצים האלה כשני קצוות של הצינור, נכוון אותם לאותו האינוד (שספירת ההתייחסות שלו תוגדר ל-2), ונסמן את האינוד כשונה ובשימוש. שימו לב לבקשות ל אני שם() בנתיבי שגיאה כדי להפחית את ספירת הפניות באינוד החדש.

pipe() חייב לעבור R0 и R1 החזר מספרי מתאר קבצים לקריאה וכתיבה. falloc() מחזיר מצביע למבנה הקובץ, אך גם "מחזיר" באמצעות u.u_ar0[R0] ומתאר קובץ. כלומר, הקוד שומר פנימה r מתאר קובץ לקריאה ומקצה מתאר קובץ לכתיבה ישירות ממנו u.u_ar0[R0] לאחר השיחה השנייה falloc().

דגל FPIPE, אותו אנו מגדירים בעת יצירת הצינור, שולט בהתנהגות הפונקציה rdwr() ב-sys2.cקריאה לשגרות קלט/פלט ספציפיות:

/*
 * common code for read and write calls:
 * check permissions, set base, count, and offset,
 * and switch out to readi, writei, or pipe code.
 */
rdwr(mode)
{
    register *fp, m;

    m = mode;
    fp = getf(u.u_ar0[R0]);
        /* … */

    if(fp->f_flag&FPIPE) {
        if(m==FREAD)
            readp(fp); else
            writep(fp);
    }
        /* … */
}

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

writep(fp)
{
    register *rp, *ip, c;

    rp = fp;
    ip = rp->f_inode;
    c = u.u_count;

loop:
    /* If all done, return. */

    plock(ip);
    if(c == 0) {
        prele(ip);
        u.u_count = 0;
        return;
    }

    /*
     * If there are not both read and write sides of the
     * pipe active, return error and signal too.
     */

    if(ip->i_count < 2) {
        prele(ip);
        u.u_error = EPIPE;
        psignal(u.u_procp, SIGPIPE);
        return;
    }

    /*
     * If the pipe is full, wait for reads to deplete
     * and truncate it.
     */

    if(ip->i_size1 == PIPSIZ) {
        ip->i_mode =| IWRITE;
        prele(ip);
        sleep(ip+1, PPIPE);
        goto loop;
    }

    /* Write what is possible and loop back. */

    u.u_offset[0] = 0;
    u.u_offset[1] = ip->i_size1;
    u.u_count = min(c, PIPSIZ-u.u_offset[1]);
    c =- u.u_count;
    writei(ip);
    prele(ip);
    if(ip->i_mode&IREAD) {
        ip->i_mode =& ~IREAD;
        wakeup(ip+2);
    }
    goto loop;
}

אנחנו רוצים לכתוב בתים לקלט הצינור u.u_count. ראשית עלינו לנעול את האינוד (ראה להלן plock/prele).

לאחר מכן אנו בודקים את מונה ההתייחסות לאינוד. כל עוד שני קצוות הצינור נשארים פתוחים, המונה צריך להיות שווה ל-2. אנחנו מחזיקים קישור אחד (מ rp->f_inode), כך שאם המונה קטן מ-2, זה חייב לומר שתהליך הקריאה סגר את קצה הצינור שלו. במילים אחרות, אנחנו מנסים לכתוב לצינור סגור, וזו שגיאה. קוד שגיאה בפעם הראשונה EPIPE ומאותת SIGPIPE הופיע במהדורה השישית של יוניקס.

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

אם יש מספיק מקום פנוי בצנרת, אנו כותבים לו נתונים באמצעות writei()... פָּרָמֶטֶר i_size1 inode (אם הצינור ריק, הוא יכול להיות שווה ל-0) מציין את סוף הנתונים שהוא כבר מכיל. אם יש מספיק שטח הקלטה, נוכל למלא את הצינור ממנו i_size1 до PIPESIZ. לאחר מכן אנו משחררים את המנעול ומנסים להעיר כל תהליך שמחכה לקרוא מהצינור. אנחנו חוזרים להתחלה כדי לראות אם הצלחנו לכתוב כמה בתים שהיינו צריכים. אם זה נכשל, אז אנחנו מתחילים מחזור הקלטה חדש.

בדרך כלל הפרמטר i_mode inode משמש לאחסון הרשאות r, w и x. אבל במקרה של צינורות, אנו מסמנים שתהליך כלשהו ממתין לכתיבה או קריאה באמצעות ביטים IREAD и IWRITE בהתאמה. התהליך קובע את הדגל ומתקשר sleep(), וצפוי שתהליך אחר כלשהו בעתיד יגרום wakeup().

הקסם האמיתי מתרחש ב sleep() и wakeup(). הם מיושמים ב slp.c, מקור ההערה המפורסמת "לא מצפים ממך להבין את זה". למרבה המזל, אנחנו לא צריכים להבין את הקוד, רק עיין בכמה הערות:

/*
 * Give up the processor till a wakeup occurs
 * on chan, at which time the process
 * enters the scheduling queue at priority pri.
 * The most important effect of pri is that when
 * pri<0 a signal cannot disturb the sleep;
 * if pri>=0 signals will be processed.
 * Callers of this routine must be prepared for
 * premature return, and check that the reason for
 * sleeping has gone away.
 */
sleep(chan, pri) /* … */

/*
 * Wake up all processes sleeping on chan.
 */
wakeup(chan) /* … */

התהליך שגורם sleep() עבור ערוץ מסוים, עלול להתעורר מאוחר יותר על ידי תהליך אחר, שיגרום wakeup() עבור אותו ערוץ. writep() и readp() לתאם את פעולותיהם באמצעות שיחות זוגיות כאלה. ציין זאת pipe.c תמיד נותן עדיפות PPIPE כשקוראים לו sleep(), אז זהו זה sleep() עלול להיקטע על ידי אות.

עכשיו יש לנו הכל כדי להבין את הפונקציה readp():

readp(fp)
int *fp;
{
    register *rp, *ip;

    rp = fp;
    ip = rp->f_inode;

loop:
    /* Very conservative locking. */

    plock(ip);

    /*
     * If the head (read) has caught up with
     * the tail (write), reset both to 0.
     */

    if(rp->f_offset[1] == ip->i_size1) {
        if(rp->f_offset[1] != 0) {
            rp->f_offset[1] = 0;
            ip->i_size1 = 0;
            if(ip->i_mode&IWRITE) {
                ip->i_mode =& ~IWRITE;
                wakeup(ip+1);
            }
        }

        /*
         * If there are not both reader and
         * writer active, return without
         * satisfying read.
         */

        prele(ip);
        if(ip->i_count < 2)
            return;
        ip->i_mode =| IREAD;
        sleep(ip+2, PPIPE);
        goto loop;
    }

    /* Read and return */

    u.u_offset[0] = 0;
    u.u_offset[1] = rp->f_offset[1];
    readi(ip);
    rp->f_offset[1] = u.u_offset[1];
    prele(ip);
}

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

בקריאות עוקבות, הצינור יהיה ריק אם היסט הקריאה הגיע i_size1 ב-inode. אנו מאפסים את המיקום ל-0 ומנסים להעיר כל תהליך שרוצה לכתוב לצינור. אנחנו יודעים שכשהמסוע מלא, writep() יירדם על ip+1. ועכשיו כשהצינור ריק, אנחנו יכולים להעיר אותו כדי לחדש את מחזור הכתיבה שלו.

אם אין לך מה לקרוא, אז readp() יכול להגדיר דגל IREAD ולהירדם על ip+2. אנחנו יודעים מה יעיר אותו writep(), כאשר הוא כותב נתונים מסוימים לצינור.

תגובות על readi() ו-writeri() יעזור לך להבין שבמקום להעביר פרמטרים באמצעות "u"אנו יכולים להתייחס אליהם כאל פונקציות I/O רגילות שלוקחות קובץ, מיקום, מאגר בזיכרון, ולספור את מספר הבתים לקריאה או כתיבה.

/*
 * Read the file corresponding to
 * the inode pointed at by the argument.
 * The actual read arguments are found
 * in the variables:
 *    u_base        core address for destination
 *    u_offset    byte offset in file
 *    u_count        number of bytes to read
 *    u_segflg    read to kernel/user
 */
readi(aip)
struct inode *aip;
/* … */

/*
 * Write the file corresponding to
 * the inode pointed at by the argument.
 * The actual write arguments are found
 * in the variables:
 *    u_base        core address for source
 *    u_offset    byte offset in file
 *    u_count        number of bytes to write
 *    u_segflg    write to kernel/user
 */
writei(aip)
struct inode *aip;
/* … */

לגבי החסימה ה"שמרנית", אם כך readp() и writep() לחסום את האינוד עד שהם מסיימים את עבודתם או מקבלים תוצאה (כלומר, התקשר wakeup). plock() и prele() לעבוד בפשטות: באמצעות סט אחר של שיחות sleep и wakeup אפשרו לנו להעיר כל תהליך שצריך את המנעול שזה עתה שחררנו:

/*
 * Lock a pipe.
 * If its already locked, set the WANT bit and sleep.
 */
plock(ip)
int *ip;
{
    register *rp;

    rp = ip;
    while(rp->i_flag&ILOCK) {
        rp->i_flag =| IWANT;
        sleep(rp, PPIPE);
    }
    rp->i_flag =| ILOCK;
}

/*
 * Unlock a pipe.
 * If WANT bit is on, wakeup.
 * This routine is also used to unlock inodes in general.
 */
prele(ip)
int *ip;
{
    register *rp;

    rp = ip;
    rp->i_flag =& ~ILOCK;
    if(rp->i_flag&IWANT) {
        rp->i_flag =& ~IWANT;
        wakeup(rp);
    }
}

בהתחלה לא הצלחתי להבין למה readp() לא גורם prele(ip) לפני השיחה wakeup(ip+1). הדבר הראשון הוא writep() גורם במחזור שלו, זה plock(ip), מה שמוביל למבוי סתום אם readp() עדיין לא הסרתי את החסימה שלי, אז איכשהו הקוד חייב לעבוד כמו שצריך. אם אתה מסתכל על wakeup(), אז מתברר שזה רק מסמן את תהליך השינה כמוכן לביצוע, כך שבעתיד sched() באמת השיק אותו. כך readp() סיבות wakeup(), מסיר את המנעול, קובע IREAD ושיחות sleep(ip+2)- כל זה לפני writep() מחדש את המחזור.

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

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

Xv6, גרעין פשוט דמוי יוניקס

כדי ליצור את הקרנל Xv6 מושפע מהמהדורה השישית של Unix, אך היא כתובה ב-C המודרנית כדי לפעול על מעבדי x86. הקוד קל לקריאה ומובן. בנוסף, בניגוד למקורות יוניקס עם TUHS, אתה יכול לקמפל אותו, לשנות אותו ולהפעיל אותו על משהו אחר מלבד PDP 11/70. לכן, גרעין זה נמצא בשימוש נרחב באוניברסיטאות כחומר חינוכי על מערכות הפעלה. מקורות נמצאים ב-Github.

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

#define PIPESIZE 512

struct pipe {
  struct spinlock lock;
  char data[PIPESIZE];
  uint nread;     // number of bytes read
  uint nwrite;    // number of bytes written
  int readopen;   // read fd is still open
  int writeopen;  // write fd is still open
};

int
pipealloc(struct file **f0, struct file **f1)
{
  struct pipe *p;

  p = 0;
  *f0 = *f1 = 0;
  if((*f0 = filealloc()) == 0 || (*f1 = filealloc()) == 0)
    goto bad;
  if((p = (struct pipe*)kalloc()) == 0)
    goto bad;
  p->readopen = 1;
  p->writeopen = 1;
  p->nwrite = 0;
  p->nread = 0;
  initlock(&p->lock, "pipe");
  (*f0)->type = FD_PIPE;
  (*f0)->readable = 1;
  (*f0)->writable = 0;
  (*f0)->pipe = p;
  (*f1)->type = FD_PIPE;
  (*f1)->readable = 0;
  (*f1)->writable = 1;
  (*f1)->pipe = p;
  return 0;

 bad:
  if(p)
    kfree((char*)p);
  if(*f0)
    fileclose(*f0);
  if(*f1)
    fileclose(*f1);
  return -1;
}

pipealloc() מגדיר את המצב של שאר היישום, הכולל את הפונקציות piperead(), pipewrite() и pipeclose(). קריאת מערכת בפועל sys_pipe הוא עטיפה המיושמת ב sysfile.c. אני ממליץ לקרוא את כל הקוד שלו. המורכבות היא ברמת קוד המקור של המהדורה השישית, אבל הרבה יותר קל ומהנה לקריאה.

לינוקס 0.01

ניתן למצוא את קוד המקור של Linux 0.01. זה יהיה מאלף ללמוד את יישום צינורות שלו fs/pipe.c. זה משתמש באינוד כדי לייצג את הצינור, אבל הצינור עצמו כתוב ב-C המודרנית. אם עברת את דרכך בקוד מהדורה XNUMX, לא תהיה לך בעיה כאן. כך נראית הפונקציה write_pipe():

int write_pipe(struct m_inode * inode, char * buf, int count)
{
    char * b=buf;

    wake_up(&inode->i_wait);
    if (inode->i_count != 2) { /* no readers */
        current->signal |= (1<<(SIGPIPE-1));
        return -1;
    }
    while (count-->0) {
        while (PIPE_FULL(*inode)) {
            wake_up(&inode->i_wait);
            if (inode->i_count != 2) {
                current->signal |= (1<<(SIGPIPE-1));
                return b-buf;
            }
            sleep_on(&inode->i_wait);
        }
        ((char *)inode->i_size)[PIPE_HEAD(*inode)] =
            get_fs_byte(b++);
        INC_PIPE( PIPE_HEAD(*inode) );
        wake_up(&inode->i_wait);
    }
    wake_up(&inode->i_wait);
    return b-buf;
}

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

ליבות לינוקס מודרניות, FreeBSD, NetBSD, OpenBSD

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

לקרוא fs/pipe.c (בלינוקס) או sys/kern/sys_pipe.c (ב-*BSD), זה דורש התמסרות אמיתית. הקוד של היום עוסק בביצועים ותמיכה בתכונות כמו וקטור ו-I/O אסינכרוני. והפרטים של הקצאת זיכרון, מנעולים ותצורת הליבה כולם משתנים מאוד. זה לא מה שמכללות צריכות לקורס מבוא למערכות הפעלה.

בכל מקרה, הייתי מעוניין לחפור כמה דפוסים ישנים (כמו יצירה SIGPIPE ותחזור EPIPE כאשר כותבים לצינור סגור) בכל הגרעינים המודרניים השונים הללו. כנראה שלעולם לא אראה מחשב PDP-11 בחיים האמיתיים, אבל עדיין יש הרבה מה ללמוד מקוד שנכתב שנים לפני שנולדתי.

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

מקור: www.habr.com