שאלה זו מתייחסת לשלבי תהליך הקריאה לשרות מערכת ההפעלה מתהליך המשתמש. עבור כל שלב בתהליך המתואר ציין אם הוא מבוצע על-ידי קוד בתהליך המשתמש, קוד בגרעין או על-ידי החומרה (מעבד) - הקף בעיגול את המתאים. עבור כל השלבים, הוסף הסבר מה השלב מבצע (הניקוד הוא נקודה לכל שורה). כדוגמה לתשובה נתונה לכם השורה הראשונה בטבלה.
Full original question text (raw OCR)
שאלה 2 - קריאות מערכת הפעלה (25 נק') 1. (10 נק') שאלה זו מתייחסת לשלבי תהליך הקריאה לשרות מערכת ההפעלה מתהליך המשתמש. עבור כל שלב בתהליך המתואר ציין אם הוא מבוצע על-ידי קוד בתהליך המשתמש, קוד בגרעין או על-ידי החומרה (מעבד) - הקף בעיגול את המתאים. עבור כל השלבים, הוסף הסבר מה השלב מבצע (הניקוד הוא נקודה לכל שורה). כדוגמה לתשובה נתונה לכם השורה הראשונה בטבלה. שלב מבוצע על-ידי | הסבר (הקף בעיגול) קריאה לפונקצית מעטפת עם פרמטרים קוד משתמש והפעלת קריאת המערכת עצמה קוד גרעין / פונקציית המעטפת אחראית לשליחת הפרמטרים לשירות במחסנית / חומרה העברת הפרמטרים קוד גרעין / לריגסטרים קוד משתמש / חומרה פקודת int 0x80 קוד גרעין / קוד משתמש / חומרה מציאת בסיס מחסנית קוד גרעין / הגרעין מתוך TSS קוד משתמש / חומרה מציאת פונקצית הטיפול בפסיקה קוד גרעין / קוד משתמש / חומרה שמירת ss,esp,eflags,cs,eip קוד גרעין / קוד משתמש למקום שמוצבע על-ידי / חומרה וכיוון ,TSS-ב esp0 ss:esp למחסנית הגרעין כיוון cs:eip למקום של קוד גרעין / שגרת הטיפול ב-int קוד משתמש 0x80 לפי ה-gate מה- / חומרה .IDT orig_eax שמירת קוד גרעין / וקריאה ל-SAVE_ALL | קוד משתמש / חומרה איתור שגרת השירות ב- קוד גרעין / + syscall_table קוד משתמש בדיקה שמספר קריאת / חומרה המערכת הוא חוק קריאה לשגרת השרות | קוד גרעין / קוד משתמש / חומרה ביצוע שגרת השירות קוד גרעין / קוד משתמש / חומרה בסעיפים הבאים (2,3,4) המתרגלים מציעים שינויים במנגנון הטיפול בפסיקות. בכל הסעיפים הבאים מערכת ההפעלה והמעבד נותרים ללא שינוי, מלבד השינוי המוצע. 2. (5 נק') אלון, מתרגל במערכות הפעלה, הציע כי בקבלת פסיקה ישמר גם רגיסטר ebx, בנוסף לרגיסטרים שנשמרו במימוש המקורי על מחסנית הגרעין. להלן שרטוט הממחיש את המימוש החדש: סדר השמירה המקורי סדר השמירה החדש בסיס המחסנית SS SS V ראש המחסנית esp eflags CS eip ebx esp eflags CS eip כדי להשלים את המימוש, אלון הציע שבחזרה מפסיקה, יישלף רגיסטר ebx ולאחר מכן ישלפו שאר הרגיסטרים כפי שהיה במימוש המקורי. האם המימוש של אלון תקין? אם לא, איזו בעיה עלולה להיווצר במימוש? א. המימוש תקין. ב. המימוש לא תקין, כי קריאות מערכת לא יוכלו לכתוב על המחסנית. ג. המימוש לא תקין, כי קריאות מערכת לא יוכלו לגשת למבנה הנתונים runqueue של הגרעין. ד. המימוש לא תקין, כי המעבד לא יוכל להבדיל בין פסיקות חומרה לחריגות (פסיקות תוכנה). ה. המימוש לא תקין, כי המעבד לא יוכל להבדיל בין פסיקות מקוננות לפסיקות לא מקוננות. ו. המימוש לא תקין, כי משתמש זדוני יוכל לגרום לקריסת המערכת ע"י הצבעה לכתובת מחסנית לא חוקית. נימוק 3. (5 נק') עידן, מתרגל במערכות הפעלה, הציע לשנות את מנגנון הפסיקות באופן אחר: עם קבלת פסיקה לא מחליפים מחסניות, דוחפים את eflags, cs, eip בלבד בראש המחסנית הנוכחית, ועוברים לבצע את שגרת הטיפול בפסיקה כפי שהיא מופיעה ב-IDT. בהתאם, בחזרה מפסיקה, שולפים את שלושת הערכים שנדחפו ונשארים במחסנית הנוכחית. האם המימוש של עידן תקין? אם לא, איזו בעיה עלולה להיווצר במימוש? א. המימוש תקין. ב. המימוש לא תקין, כי קריאות מערכת לא יוכלו לכתוב על המחסנית. ג. המימוש לא תקין, כי קריאות מערכת לא יוכלו לגשת למבנה הנתונים runqueue של הגרעין. ד. המימוש לא תקין, כי המעבד לא יוכל להבדיל בין פסיקות חומרה לחריגות (פסיקות תוכנה). ה. המימוש לא תקין, כי המעבד לא יוכל להבדיל בין פסיקות מקוננות לפסיקות לא מקוננות. ו. המימוש לא תקין, כי משתמש זדוני יוכל לגרום לקריסת המערכת ע"י הצבעה לכתובת מחסנית לא חוקית. נימוק 4. (5 נק') יהונתן, מתרגל במערכות הפעלה, הציע לשנות את סדר שמירת הרגיסטרים בקבלת פסיקה באופן אחר: סדר השמירה המקורי סדר השמירה החדש בסיס המחסנית SS CS V ראש המחסנית eip eflags SS esp esp eflags CS eip כדי להשלים את המימוש, יהונתן הציע שבחזרה מפסיקה, יישלפו הרגיסטרים בהתאמה לסידור החדש. האם המימוש של יהונתן תקין? אם לא, איזו בעיה עלולה להיווצר במימוש? א. המימוש תקין. ב. המימוש לא תקין, כי קריאות מערכת לא יוכלו לכתוב על המחסנית. ג. המימוש לא תקין, כי קריאות מערכת לא יוכלו לגשת למבנה הנתונים runqueue של הגרעין. ד. המימוש לא תקין, כי המעבד לא יוכל להבדיל בין פסיקות חומרה לחריגות (פסיקות תוכנה). ה. המימוש לא תקין, כי המעבד לא יוכל להבדיל בין פסיקות מקוננות לפסיקות לא מקוננות. ו. המימוש לא תקין, כי משתמש זדוני יוכל לגרום לקריסת המערכת ע"י הצבעה לכתובת מחסנית לא חוקית. נימוק
קריאה לפונקצית מעטפת עם פרמטרים במחסנית
System call trap and kernel entrylibc syscall wrapper caching pitfallsLocal vs global interrupt disableהעברת הפרמטרים לריגסטרים
System call trap and kernel entrylibc syscall wrapper caching pitfallsLocal vs global interrupt disableפקודת int 0x80
System call trap and kernel entryמציאת בסיס מחסנית הגרעין מתוך TSS
System call trap and kernel entrylibc syscall wrapper caching pitfallsLocal vs global interrupt disableמציאת פונקצית הטיפול בפסיקה
Local vs global interrupt disableשמירת ss,esp,eflags,cs,eip למקום שמוצבע על-ידי TSS.esp0 וכיוון ss:esp למחסנית הגרעין
System call trap and kernel entrylibc syscall wrapper caching pitfallsLocal vs global interrupt disableכיוון cs:eip למקום של שגרת הטיפול ב-int 0x80 לפי ה-gate מה-IDT.
System call trap and kernel entryשמירת orig_eax וקריאה ל-SAVE_ALL
System call trap and kernel entrylibc syscall wrapper caching pitfallsLocal vs global interrupt disableאיתור שגרת השירות ב-syscall_table + בדיקה שמספר קריאת המערכת הוא חוקי
libc syscall wrapper caching pitfallsקריאה לשגרת השרות
System call trap and kernel entrylibc syscall wrapper caching pitfallsLocal vs global interrupt disableביצוע שגרת השירות
System call trap and kernel entrylibc syscall wrapper caching pitfallsLocal vs global interrupt disable(5 נק') אלון, מתרגל במערכות הפעלה, הציע כי בקבלת פסיקה ישמר גם רגיסטר ebx, בנוסף לרגיסטרים שנשמרו במימוש המקורי על מחסנית הגרעין. להלן שרטוט הממחיש את המימוש החדש: כדי להשלים את המימוש, אלון הציע שבחזרה מפסיקה, יישלף רגיסטר ebx ולאחר מכן ישלפו שאר הרגיסטרים כפי שהיה במימוש המקורי. האם המימוש של אלון תקין? אם לא, איזו בעיה עלולה להיווצר במימוש? א. המימוש תקין. ב. המימוש לא תקין, כי קריאות מערכת לא יוכלו לכתוב על המחסנית. ג. המימוש לא תקין, כי קריאות מערכת לא יוכלו לגשת למבנה הנתונים runqueue של הגרעין. ד. המימוש לא תקין, כי המעבד לא יוכל להבדיל בין פסיקות חומרה לחריגות (פסיקות תוכנה). ה. המימוש לא תקין, כי המעבד לא יוכל להבדיל בין פסיקות מקוננות לפסיקות לא מקוננות. ו. המימוש לא תקין, כי משתמש זדוני יוכל לגרום לקריסת המערכת ע"י הצבעה לכתובת מחסנית לא חוקית. נימוק
libc syscall wrapper caching pitfallsLocal vs global interrupt disable(5 נק') עידן, מתרגל במערכות הפעלה, הציע לשנות את מנגנון הפסיקות באופן אחר: עם קבלת פסיקה לא מחליפים מחסניות, דוחפים את eflags, cs, eip בלבד בראש המחסנית הנוכחית, ועוברים לבצע את שגרת הטיפול בפסיקה כפי שהיא מופיעה ב-IDT. בהתאם, בחזרה מפסיקה, שולפים את שלושת הערכים שנדחפו ונשארים במחסנית הנוכחית. האם המימוש של עידן תקין? אם לא, איזו בעיה עלולה להיווצר במימוש? א. המימוש תקין. ב. המימוש לא תקין, כי קריאות מערכת לא יוכלו לכתוב על המחסנית. ג. המימוש לא תקין, כי קריאות מערכת לא יוכלו לגשת למבנה הנתונים runqueue של הגרעין. ד. המימוש לא תקין, כי המעבד לא יוכל להבדיל בין פסיקות חומרה לחריגות (פסיקות תוכנה). ה. המימוש לא תקין, כי המעבד לא יוכל להבדיל בין פסיקות מקוננות לפסיקות לא מקוננות. ו. המימוש לא תקין, כי משתמש זדוני יוכל לגרום לקריסת המערכת ע"י הצבעה לכתובת מחסנית לא חוקית. נימוק
libc syscall wrapper caching pitfallsLocal vs global interrupt disable(5 נק') יהונתן, מתרגל במערכות הפעלה, הציע לשנות את סדר שמירת הרגיסטרים בקבלת פסיקה באופן אחר: כדי להשלים את המימוש, יהונתן הציע שבחזרה מפסיקה, יישלפו הרגיסטרים בהתאמה לסידור החדש. האם המימוש של יהונתן תקין? אם לא, איזו בעיה עלולה להיווצר במימוש? א. המימוש תקין. ב. המימוש לא תקין, כי קריאות מערכת לא יוכלו לכתוב על המחסנית. ג. המימוש לא תקין, כי קריאות מערכת לא יוכלו לגשת למבנה הנתונים runqueue של הגרעין. ד. המימוש לא תקין, כי המעבד לא יוכל להבדיל בין פסיקות חומרה לחריגות (פסיקות תוכנה). ה. המימוש לא תקין, כי המעבד לא יוכל להבדיל בין פסיקות מקוננות לפסיקות לא מקוננות. ו. המימוש לא תקין, כי משתמש זדוני יוכל לגרום לקריסת המערכת ע"י הצבעה לכתובת מחסנית לא חוקית. נימוק
libc syscall wrapper caching pitfallsLocal vs global interrupt disable
The exam question — original PDF
pages 7, 8, 9, 10, 11Exactly as it appears on the exam paper.
Built from these components
Ordered basic → advanced. Master the earlier ones first.
Review the material
Read these before you answer — each verified slide teaches a component this question tests, and nothing from an unrelated topic is included. Tutorial slides show the actual slide image.
אחרי fork()parentint main() { int x = 0; pid_t p = fork(); if (p == 0) { x = 1; } else { x = 2; }}sonint main() { int x = 0; pid_t p = fork(); if (p == 0) { x = 1; } else { x = 2; }}מערכות הפעלה - תרגול 210
הדפסה מתואמת למסךשימוש ב-wait() יכול לפתור את הבעיה שראינו קודם כאשר מדפיסים למסך במקביל משני תהליכים:int main() { pid_t p = fork(); if (p > 0) { // parent waits for child wait(NULL); } printf(“hello”); return 0;}מערכות הפעלה - תרגול 215
קריאת המערכת waitpid()pid_t waitpid(pid_t pid, int *wstatus, int options);פעולה: המתנה לסיום בן ספציפי שמספרו pid.wait(), waitpid() הן קריאות מערכת חוסמות.כלומר חוסמות את התקדמות התהליך עד להתרחשות תנאי מסוים.באנגלית: blocking system calls.הארגומנט options מאפשר לשנות את ההתנהגות של waitpid() לקריאת מערכת לא חוסמת.אם options==WNOHANG קריאת המערכת תחזור מיד, כאשר ערך חזרה 0 משמעותו שאף תהליך בן עוד לא סיים, ואילו ערך חזרה חיובי הוא ה-pid של תהליך בן שסיים ונמצא עדיין במצב zombie.מערכות הפעלה - תרגול 216
קריאת המערכת exit()שאלה: למה בכלל לקרוא ל-exit(status) , אם אפשר פשוט לרשום return status בסוף פונקציית ה-main?תשובה: main היא לא באמת הפונקציה הראשית של התכנית...main() נקראת ע"י __libc_start_main() שאוספת את ערך החזרה של main() וקוראת ל-exit().int __libc_start_main(…) { …… exit(main(…));}מסקנה: הפונקציה exit תמיד נקראת לסיום סטנדרטי של התוכנית.מערכות הפעלה - תרגול 218
קריאות המערכת getpid(), getppid()pid_t getpid();קריאת מערכת המחזירה לתהליך הקורא את ה-pid של עצמו.pid_t getppid();קריאת מערכת המחזירה את ה-PID של תהליך האב של התהליך הקורא.שאלה: מה המשמעות של getppid() == 1 עבור תהליך משתמש טיפוסי?תשובה: תהליך האב הוא init. קורה למשל אם תהליך הבן יתום.מערכות הפעלה - תרגול 222
דוגמת קודמסכמתprintf("pid = %d\n", getpid());pid_t pid = fork();if (pid == 0) { printf("child pid = %d\n", getpid()); char* args[] = {"/bin/date", NULL}; execv(args[0], args); printf("This should not be printed\n");} else { wait(NULL); printf("parent pid = %d\n", getpid());}פלט לדוגמה:pid = 8919child pid = 8920Sun Oct 29 00:31:32 IDT 2017parent pid = 8919מערכות הפעלה - תרגול 224
אתחול תהליכים בלינוקסמשתמשים מתחברים לעבודה בלינוקס דרך מסופים (terminal).מסוף = מסך + מקלדת (מקומי או מרוחק).התהליך init יוצר תהליך בן עבור כל מסוף, אשר טוען ומבצע את המשימות הבאות לפי הסדר:איתחול של המסוף.התחברות של המשתמש עם שם משתמש וסיסמא באמצעות תכנית login.אם אושרה כניסת המשתמש: קריאה לתוכנית shell(כמו tcsh או bash) המאפשרת למשתמש להעביר פקודות למערכת ההפעלה.מערכות הפעלה - תרגול 225
דוגמה לשימוש בתהליכים - shellממשק שורת פקודה (command line).ייעוד עיקרי: לקבל פקודות ולבצע אותן באופן סדרתי.ה-shell מייצר תהליך בן עבור כל פקודה על-מנת לבצע אותה.כל פקודה ניתן להריץ בחזית (foreground) או ברקע (background).הרצה בחזית: האב (shell) ממתין לסיום הבן לפני קריאת הפקודה הבאה.הרצה ברקע: האב (shell) עובר מיד לקריאת הפקודה הבאה.ייעוד נוסף: להציג קבצים ותיקיות על-מנת לסייר במערכת.דוגמה חיה:https://www.tutorialspoint.com/unix_terminal_online.phpמערכות הפעלה - תרגול 226
מערכות הפעלה - תרגול 2281שאלה ממבחן
תרגול 8מנגנוני סנכרון: משתני תנאימנגנוני סנכרון: סמפוריםדוגמה: מימוש מנעול קוראים-כותביםסינכרון בגרעין לינוקס1מערכות הפעלה - תרגול 8
שחרור חוטים ממתיניםint pthread_cond_signal(pthread_cond_t *cond); משחררת את אחד החוטים הממתינים (הגינות לא מובטחת).int pthread_cond_broadcast(pthread_cond_t *cond);משחררת את כל החוטים הממתינים.כל החוטים מפסיקים להמתין על משתנה התנאי ועוברים להמתין על המנעול. החוטים יחזרו לפעילות בזה אחר זה (בסדר כלשהו, לאו דווקא הוגן) לאחר שינעלו מחדש את ה-mutex.שימו לב: אם אין אף חוט שממתין באותו רגע על משתנה התנאי cond, הפעולות חסרות השפעה (הסיגנל הולך לאיבוד ואינו נזכר הלאה).ערך מוחזר: הפונקציות תמיד מצליחות ומחזירות 0.מערכות הפעלה - תרגול 812
The exam text, the skills it tests, and the exact slides are already in context.