4002 אוטווה לינוקס סימפוזיום  
אורנה אגמון ומולי בן-יהודה

Dan Aloni (First Israeli Speaker!!):Cooperative Linux

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

Keith Packard, (HP, Xfree developer) - Getting X Off the Hardware

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

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

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

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

James Bottomley (SteelEye Technology, Inc.) - Improving Kernel Performance by Unmapping the Page Cache

כ-%51 משטח השבב של המעבד מוקדש לקאש 1L. כיום יש עד 4 רמות זכרון מטמון (קאש), בארכיטקטורות מסויימות. רמות זכרון המטמון יכולות להיות אקסקלוסיביות (המידע מופיע רק באחת הרמות, אם הוא מופיע בה בכלל) או אינקלוסיביות (המידע המופיע בהן עשוי להופיע בכמה רמות בו זמנית).

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

PIPT
Physically Indexed, Physically Tagged.
אפשר להשתמש בשיטה זו רק עבור כתובות פיזיקליות, ואנחנו עובדים בזכרון וירטואלי.
VIPT
Virtually Indexed, Physically Tagged.
VIVT
Virtually Indexed, Virtually Tagged.
השיטה הכי מהירה אם מוצאים את השורה הדרושה, אחרת מוסיף פיגור סריאלי.
הבעייה בה רוצים להלחם היא אליאס: מצב בו אותה כתובת ממופה פעמיים בזכרון המטמון. זה קורה כאשר אותו זכרון פיזיקלי ממופה לשני זכרונות וירטואליים שונים, למשל עבור הספריה CBILG. במערכת TVIV לא ניתן למנוע תופעה זו, אך במערכת TPIV ניתן. במערכת TPIP אין מצב כזה בכלל.

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

לכן בארכיטקטורות עתידיות, חיבים להשתמש ב-TPIV.

ניתן לחשוב על הצעת פתרון - למפות את כל הזכרונות של המרחב המשתמש באותה צורה, אבל הקרנל עדיין ימופה באופן שונה.0088AP, הארכיטקטורה החדשה של PH, אכן משתמשת בTPIV.

העבודה שבוצעה:

Hanna Linder (IBM) - BOFS(Birds Of a Feather Session) : Linux Scalability Effort

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

יש צורך בתמיכה טובה ב SFN. יש שביעות רצון כללית מן ה IPA של אנדי קלין מסוסה. גם רד-האט משלבת את החבילה שלו (ליבנומא). מפתח בשם אולי (אולריך דרפר, האחראי על CBILG), שהתנגד לIPA בשעתו, לא עובד על הנושא. AMUNBIL נתן שיפור של %01-51 בביצועים על איטניום כפול 23.

התעורר ויכוח על השאלה "האם צומת ללא מעבד היא עדיין צומת". הוחלט להשתמש במינוח במוכלל NIAMOD YTIMIXORP, כדי להביע משהו שמענין מה המרחק אליו. זה יכול להיות צומת עם מעבד, זכרון, או אף התקן קלט-פלט בלבד.

ב EHCACD יש בעית הסתלמות (סקלביליות) - אם פותחים וסוגרים הרבה קבצים.

רעיון של ריק ון ריל: להשתדל להקצות זכרון ששוחרר, שהיה בעבר על אותו צומת, באותו מקום, כדי שיהיה מיחזור של SEIRTNED .

Rik van Riel: Improving Linux resource control using CKRM

CKRM = Class-based Kernel Resource Management-
ניהול משאבי ליבה בהתבסס על מחלקות. מתן עדיפות לפי קבוצות של משתמשים, או לפי סוג העבודה המבוצעת - לדוגמא, עדיפות מיוחדת לתוכנות הידועות כמטפלות בדוא"ל. למחשב המשמש כדסקטופ ניתן להגדיר למשל העדפה כך שלפחות %05 מן הזכרון ומן המעבד מוקדשים לתצוגה, כך שפעילות אינטנסיבית ברקע לא תפריע למשתמש. ניתן למשל להגביל את הדפדפן, כך שלא יגזול מעבר לאחוז מסויים של המשאבים.

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

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

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

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

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

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

http://ckrm.sf.net

Paul "Rusty" Russel (IBM): Linux Kernel Hotplug CPU Support

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

פתרונות אפשריים:

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

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

Dave Hansen (IBM): Hotplug Memory and the Linux VM

הכתובות הוירטואליות נשארות קבועות במהלך התהליך. יש הרבה זכרון שמוקצה בזמן הבוט, והוא בעייתי. בעיות:

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

Jon Paul Maloy (Ericsson): TIPC: Providing Communication for Linux Clusters

TIPC=Transparent Inter Process Communication
מדוע צריך עוד פרוטוקול? PCT כללי מדי ובלתי יעיל. PDU - בלתי אמין. שקעי יוניקס - רק עבור צומת אחד. צריך פרוטוקול אמין ומהיר אחד, שקוף למיקום. הידיעה האם הצומת אכן נמצא היא בונוס שהתקבל מן הפרוטוקול המוצע.

הפרוטוקול פועל ישירות על המדיה (את'רנט, אינפיניבנד), אחרת מעל PI. ב - %08 מהיר יותר מPCT לוקאלי לצומת. ב %53 מהיר יותר מאשר PCT בין צמתים, עבור הודעות קצרות.

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

הפרוטוקול במצב "בטא". בטוח להוריד ולנסות. אין תמיכה באבטחת מידע. למידע נוסף:

http://tipc.sf.net"

Sam Robb (TimeSys) Creating Cross-Compile Friendly Software

בקרוס-קומפילציה מדברים על מערכת בניה, מערכת מארחת ומערכת יעד. מערכת היעד נכנסת לבעיה רק כאשר הקוד שמהדרים הוא בעצמו מהדר, או יוצר קוד באופן אחר. הקוד נבנה במערכת הבניה, ומיועד לרוץ על מערכת מארחת.
AC_TRY_COMPILE AC_TRY_LINK
במקום לנסות להריץ קוד, מה שלא יעבוד.
AC_ARG_ENABLE,--enable-x
כדי לאפשר למשתמש לקבוע במפורש משתנה. צריך לבדוק האם המשתמש הגדיר, לפני שמגדירים אוטומטית.

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

כלים רבים שעובדים על קבצים לביצוע עלולים לעבוד על מערכת הבנייה, אך לתת תוצאות שגויות על קבצים המיועדים לביצוע על המערכת המארחת. למשל: xe, ra, pirts.

שמות כלים "מעוטרים" עלולים לאבד את עיטוריהם. למשל:

AR=@AR@ cq
הזנה של RA במפורש עלולה לגרום לאיבוד העיטורים. עדיף להגדיר את הפרמטרים שמקבל הכלי בנפרד.

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

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

כדאי לשלב יכולות בדיקה עצמית , שיכללו ביצוע, ניתוח התוצאות ודיווח.

כיצד לשכנע מעסיקים לתת למפתחים לתרום חזרה לתוכנת קוד פתוח / לשחרר קוד כקוד פתוח

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

שיווק

עלות

טכנולוגיה

אחר

Harald Marc Welte: GPL Violations

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

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

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

איך להגן בקלות על הפרת רשיון הקוד שלכם?

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

Linux Virtualization

There was a lot of interest this year in virtualization, both in the sense of making Linux easier to virtualize and using Linux as a host for virtual guests. Chris Wright of OSDL gave an introduction to virtualization, Dan Aloni talked about coLinux, and Ian Pratt of Cambridge talked about Xen. There were also several talks and BOFs on virtualization related subjects such as CPU and Memory Hotplug and Jiffies-less systems. We also held a long and interesting bar BOF on virtualization, attended by IBMers (research hypervisor and others), VMWare folks, Xen, coLinux and others.

Chris Wright started with a review of what is virtualization and what is it good for. He reviewed the history of virtualization (in which IBM plays a significant role), and then discussed different virtualization techniques.

Complete virtualization includes Processor Emulation (implemented by tools such as Bochs, QEMU and valgrind), Virtual OS (e.g. UML) and Virtual Machine (implemented by VMWare and Xen).

Partial Virtualization includes Linux-Vserver (provide multiple concurrent execution context within the confines of a single Linux kernel), the Linux Virtual Server (IPVS) project (network load balancer) and even the standard unix chroot() command, if you take a liberal enough interpretation of "virtualization".

Xen

Xen is a virtual machine monitor, developed by the University of Cambridge Computer Laboratory. Unlike VMWare, which provides complete virtualization, guest operating systems need to be ported to the Xen environment. So far, Linux 2.4 and 2.6 have been ported, as well as NetBSD, FreeBSD and Plan9, and Windows XP. The Windows XP port was done in collaboration with MS Research, and took much longer than the Linux port...

Xen works by letting the monitor (hypervisor) run in ring 0, and the guest OS run in ring 1. Userspace runs in ring 3, as usual. From a Linux point of view, porting Linux to Xen (refereed to as XenoLinux) is just a matter of implementing the arch specific hooks in Linux - no core kernel files are modified!

Xen provides secure protection between VMs (unlike e.g. coLinux), allows flexible partitioning of resources, and supports seamless low-latency migration of running VMs(!). They also claims impressive performance numbers, within 3% of the host performance.

Virtualization BOF

One unplanned but welcome event that took place during OLS was a virtualization BOF, attended by IBM Research folks working on a research hypervisor, VMWare folks, the Xen and coLinux folks, and yours truly. We discussed common issues that plague all virtualization solutions, such as virtualizing the X86 architecture, how to handle time in a virtual machine, which nomenclature to use (monitor or hypervisor? domain, guest, partition?) and how to get buy-in from the Linux community.

Two concrete outcomes from the BOF are a new Virtualization Mailing List and a Linux Virtualization wiki. Anyone interested is welcome to join.

It appears that Xen is the most likely virtualization candidate for mainline kernel inclusion, due to the low pain factor in merging it.

New Kernel Development Model

During the 2004 Kernel Summit, the lead kernel developers met and discussed a so-called change to the kernel development model. Why "so-called change"? because what they discussed is the way we've been doing things ever since 2.6 came out.

Basically, rather than have a stable (e.g 2.4) and development (e.g. 2.5) trees, there will only be one tree, linux-2.6, which will continue to develop in the current rate. Patches will be tested in Andrew Morton's 2.6-mm tree, which will remain bleeding-edge, and once they've been proven useful and non-harmful, they will be merged to 2.6.

But what if I want a really stable kernel? in that case, use your distro's kernel. The distros are those who've been providing really stable kernels for the last few years, and we see no reason for it to change.

But what about really intrusive patches, like page clustering, shared page tables and other things of their ilk? for those patches, if and when Linus decides to merge them, he will create a short-lived 2.7 "branch" in bitkeeper. If the branch proves itself, it will be merged back into 2.6 fairly rapidly. If the branch proves to be a dud, it will be excised from the tree fairly rapidly. In any case, it will be kept in sync with 2.6. The goal is to keep the development kernel fairly stable while still progressing rapidly. Linus and Andrew are an excellent team and this new development model plays to their strengths.

Infiniband BOF

Several of the Linux developers stopped by the Infiniband BOF. Judging by the mailing list traffic, I was expecting fireworks. However, the discussion was mostly subdued, probably due to the late hour, but it was clear that if the IB folks want to ever consider mainline inclusion, they must mend their non-Linuxy ways and code.

Andrew Morton's Keynote Speech

"The most important and successful free software is system software: software which other software builds upon to provide a service". Andrew then proceeded to give some economic theories for why this is the case, warning the audience not to take economic theories from anyone, especially kernel hackers, too seriously.

Andrew mentioned that there was a large emphasis, mostly enterprise customers and vendors driven, on scalability during the last few years. We scale pretty well to 32 CPUs... new features which are currently under consideration are mainly in the area of RAS. Things like crash dump, fault hardening and recovery, standardized driver logging, etc.

IT providers who are now adopting Linux are bringing new requirements, which are sometimes hard for the developers to understand. Education on the part of the patch submitter or requester is crucial. What does this do, what is it good for? As for "why should the developers care", everyone benefits if the code ends up in the main tree.

Forking the kernel tree, except as an alternate tree that diverges from mainline and is resynched periodically, are too expensive and unlikely to occur. Alternate trees that continually diverge are bad for the maintainer and for the users (divergent stacks and APIs). Andrew will actively undermine the distro's attempts to differentiate based on different kernel offerings (audience applause).

"There's an analogy we can draw here: We know that the way Linux has progressed over the past five years or so is to enter organizations at the bottom - initial entry was via an individual sysadmin or programmer who is sick of resetting or reinstalling Windows boxes. He brings in a Linux server. Linux works, so a few more boxes are brought in. Soon Linux becomes acceptable to decision makers and ends up propagating throughout the organization. We've all heard the stories. I did it myself at Nortel. Well, I think a similar process is coming into play as corporate programmers are assigned to sit in their cubicles and work on Linux. They come in as good little corporate people but some of them are subverted. We end up taking over their brains and owning them. They become members "of the community". They become Free software developers. Some of these guys are going to be promoted into management, so in a few years time we'll have lots little preprogrammed robotic penguins infiltrating the corporate hierarchy imparting clues in upward, downward and sideways directions. So this is the real reason why we're applying their patches. Rest assured: world domination is proceeding according to plan."