הוטפלאג מעורר שאלות שעד כה ל-X לא היה צורך לעסוק בהן: למשל, האם כרטיס גרפי חדש ישתלב באותו שרת X שכבר קיים, או יוגדר לו שרת X חדש? הרבה קוד מתבסס על כך שהמסך מוגדר בעת איתחול המחשב (מסתמך על כך שתהליך האב הישיר או הקרוב הינו TINI).
אז מה אמור לקרות כשמנתקים עכבר, ומחברים עכבר באותו מקום? אולי העכבר החדש יקבל מספור פנימי חדש, אבל כלפי חוץ צריך לשמור על טופולוגיית החיבורים, ולהניח שזה אותו עכבר.
תפיסה חדשה מתעוררת: הסתמכות על כלי מרחב משתמש כדי לקנפג דברים: "זה בסדר לקרוא לתוכניות מרחב משתמש". כיום הדרך היחידה לקנפג כרטיסים מסויימים היא דרך ה-SOIB, כי לאינטל אין את הזכויות על הדוקומנטציה של הכרטיסים.
שורה בזכרון המטמון מורכבת מאינדקס, מידע ותווית, המסמנת שהמידע אכן נכון. אפשריות שלוש שיטות של קביעת סוגי האינדקסים והתוויות:
אם זה זכרון לקריאה בלבד, הבעייה אינה חמורה. אם הזכרון ניתן גם לכתיבה, יש בעייה, מכיוון שזכרון המטמון אחראי על הכתיבה לזכרון. אם יש שני עותקים מלוכלכים של השורה (כלומר השורה עברה שינוי פעמיים, בכנוייה השונים), יש בעייה חמורה.
לכן בארכיטקטורות עתידיות, חיבים להשתמש ב-TPIV.
ניתן לחשוב על הצעת פתרון - למפות את כל הזכרונות של המרחב המשתמש באותה צורה, אבל הקרנל עדיין ימופה באופן שונה.0088AP, הארכיטקטורה החדשה של PH, אכן משתמשת בTPIV.
העבודה שבוצעה:
העבודה מתמקדת בכך ש- LAMRON_ENOZ כבר לא ממופה אוטומטית למרחב הכתובות של הקרנל, אלא ממופה רק כשצריך, כמו MEMHGIH_ENOZ.
דיון פתוח - מאורגן בנושא לינוקס על מכונות מרובות צמתים.
יש צורך בתמיכה טובה ב SFN. יש שביעות רצון כללית מן ה IPA של אנדי קלין מסוסה. גם רד-האט משלבת את החבילה שלו (ליבנומא). מפתח בשם אולי (אולריך דרפר, האחראי על CBILG), שהתנגד לIPA בשעתו, לא עובד על הנושא. AMUNBIL נתן שיפור של %01-51 בביצועים על איטניום כפול 23.
התעורר ויכוח על השאלה "האם צומת ללא מעבד היא עדיין צומת". הוחלט להשתמש במינוח במוכלל NIAMOD YTIMIXORP, כדי להביע משהו שמענין מה המרחק אליו. זה יכול להיות צומת עם מעבד, זכרון, או אף התקן קלט-פלט בלבד.
ב EHCACD יש בעית הסתלמות (סקלביליות) - אם פותחים וסוגרים הרבה קבצים.
רעיון של ריק ון ריל: להשתדל להקצות זכרון ששוחרר, שהיה בעבר על אותו צומת, באותו מקום, כדי שיהיה מיחזור של SEIRTNED .
עבור אירוח וירטואלי, ניתן להשתמש במנגנון זה כדי להגביל את השימוש במשאבים של אתר מתארח, כדי שלא יפגע באחרים. המנגנון פותר גם את הבעיה של מערכת עמוסה כל כך שלא ניתן להתחבר אליה ולטפל בבעיה, כי אין די שקעים. בעתיד מתוכננת מערכת קבצים לפי אותו עיקרון (SFCR).
ניתן להעביר משימות בין מחלקות. לשם כך צריך הרשאה לכתוב לקובץ של המחלקה, כמו גם הרשאה לשלוח סיגנל למשימה.
יש אפשרות למנועי סיווג: המנועים מבוססים על סט חוקים. בכל פעם שמתרחש ארוע, למשל יצירת משימה, מתבצע מעבר על החוקים.
נתחים בעוגה: תהליך ההורה מספק את הנתח ההתחלתי. תהליך ילד מקבל חלק מן הנתח של ההורה. בסך הכל ארבעה מספרים מגדירים את הנתח שמקבל התהליך בפועל. ניתן להגדיר נתחים מתוך מעבד, קלט פלט, זכרון פיזי ועוד.
לכל מחלקה יש זמן. באופן בסיסי מבצעים זימון בין המחלקות, ואז זימון בתוך המחלקה עצמה. התקורה קטנה - 6.2 מיקרושנייה. זאת בזכות האלגוריתמים העצלים המשמשים להשגחה ולדיווח.
אם יש מגבלה באחוזים על התהליך, אבל אף אחד אחר לא משתמש במשאב, התהליך יקבל הכל. אם יש חסם בצורת רף אבסולוטי, התהליך יוגבל גם אז. למידע נוסף:
פתרונות אפשריים:
הורדת המעבד: אין הורדה של יותר ממעבד אחד בו זמנית. התהליך כולל: לקיחת הסמפור של השליטה במעבדים, בדיקה שיש לפחות שני מעבדים מחוברים, בדיקה שמעבד היעד אכן מחובר, הזזת תהליכים מן המעבד (חריג מבחינת הדבקות בהוראת המשתמש להצמד למעבד מסויים), עצירת המעבד.
יש מודול זכרון בהוטפלאג עבור 68X ועבור CPP, וצפוי שילוב בקרנל בשלב מוקדם של 7.2 (וראו מודל פיתוח הקרנל העתידי).
הפרוטוקול פועל ישירות על המדיה (את'רנט, אינפיניבנד), אחרת מעל PI. ב - %08 מהיר יותר מPCT לוקאלי לצומת. ב %53 מהיר יותר מאשר PCT בין צמתים, עבור הודעות קצרות.
כרגע הפרוטוקול עובד רק עבור צמתים שמקושרים פיזית. הפרוטוקול נותן מידע נוסף כמו מידע על שכנים ברשת ועל טופולוגית הרשת, המתעדכן דינמית. (רק) כאשר לא עובר כל מידע ברשת, המידע על טופולוגית הרשת וקיומה נשמר באמצעות העברת "פעימות לב".
הפרוטוקול במצב "בטא". בטוח להוריד ולנסות. אין תמיכה באבטחת מידע. למידע נוסף:
יש להזהר בהנחת הנחות על המערכת המארחת. הנחות אלו עשויות להיות נכונות על מערכת הבניה. (חשבו על הידור לצורך הרצה על מערכת לינוקס משובצת):
שמות כלים "מעוטרים" עלולים לאבד את עיטוריהם. למשל:
נתיבים שמקודדים בתוך הקוד - מסוכן מאד. בייחוד כשמדובר בכלילת קבצים, והמערכת השנייה דומה מאד. עלול להצליח, אבל להביא את הקבצים הלא נכונים, מתוך ספריה לא נכונה.
יש להתמודד עם האפשרות שהמערכת המארחת אינה שלמה לחלוטין. ייתכן שספריות מבויימות לא נוצרו עדיין.
כדאי לשלב יכולות בדיקה עצמית , שיכללו ביצוע, ניתוח התוצאות ודיווח.
הפרות LPG מסויימות נעשות תוך שימוש בהסכם חסיון מידע, המקשה על מגלי הפרת הרשיון החופשי ליידע את בעלי הזכויות על כך. שיטות מתוחכמות יותר יוצרות גרסה אישית של המוצר לכל לקוח, כך שניתן לגלות איזה לקוח הדליף את המידע.
ניתן לתבוע את מפרי הLPG בארץ בה התרחשה ההפרה, אין צורך להגיע לארץ בה רשומה החברה. לכן ולטה יכול היה לתבוע את החברה בגרמניה - הם מכרו ישירות לציבור הגרמני, ללא חברה מתווכת.
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 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.
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.
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.
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.
"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."