פתרון פרויקט רכיב קרנל עם כלי משתמש

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

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

הסגירה של fd מפסיקה קבלה עבור אותו open context ומטפלת בעבודה שנותרה בבעלותו. אם work item עדיין מחזיק reference, context אינו נמחק רק משום שהמשתמש סגר את המתאר. הסרת הרכיב מפסיקה גם מקורות עבודה חדשים ומחכה לפי מנגנוני הkernel הרלוונטיים.

הלקוח הישן מקבל את אותה פריסת תשובה עבור בקשות ישנות. הלקוח החדש בודק capability או גרסה לפני שימוש בסוג החדש. ההרחבה אינה מוסיפה שדה באמצע struct קיים ומשאירה את המספר הישן של ABI כאילו דבר לא השתנה.

הבדיקות מפרידות בין מודל state machine לבין מסלול kernel אמיתי. המודל מונה סדרי cancel וcompletion, והבדיקה בVM מכריחה close, עומס וteardown. תוצאת build או metadata של לקוח Rust אינה ראיה לכך שהdriver נטען או שKUnit רץ.

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