MicroKernelיהו...

MotiAd

New member
MicroKernelיהו...

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

אלדד28

New member
איש אמיץ אתה

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

MotiAd

New member
hehehe....

not neccesarly, i am just curious(jokingly). it isn't such a good idea for specific implemetations. i am not talking about exokernel and such. what i mean is that it will be a better idea to make the changble parts of the kernel like modules. (saying file system implementations or device supporting), because forcing the kernel to support only some of those devices or filesysetms is not somthing i want. i want to create a situation in which a user will bring a file named ext3fs.m and place it in a specific direcctory that the kernel knows to search there for filesystem imp's and then load it when neccesary. this is the basic idea i want to present. maybe even go further and let the user choose what threads like imp' he likes (byt for now this is too much). this is the basic idea and i don't want to make them as drivers are. is that such a bad idea for this approach? is there somthing better? i would like to hear opinions. Yours, Moti. (the english is because i write from BSD)
 

אלדד28

New member
זה לא סותר,

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

MK מונוליטי *אמור* לתת ביצועים יותר טובים, בגלל שלא צריך IPC. האם לזה התכוונת?
 

gilad_no

New member
זה זניח

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

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

אלדד28

New member
זה לא נכון,

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

הקרנל של NT, כמו שציינתי הוא בארכיטקטורת MK. הוא לא מונוליטי, אבל הגישה שלהם היתה כזו, שלמעשה כל מודול של הקרנל רץ ב-THREAD נפרד במקום ב-PROCESS נפרד. כך משיגים ביצועים טובים יותר מאשר בגישה הקלאסית של MK (שבה יש צורך לבצע IPC בין מודולי הקרנל), ועדיין בלי הצורך לקודד במודל מונוליטי. ישנה שכבה שלמה במודל הקרנל של NT, שהיא נפרדת לחלוטין (מבחינה הנדסית) מהקרנל עצמו. היא לא מגיעה עם ההתקנה, אתה יכול לשנות אותה, להוסיף לה, להוריד ממנה וכו'. כמו כן, NT מאפשר ניתוק והוספת של מודולים בזמן ריצה, אבל לא את כולם. אני כן מסכים שהגישה התיאורטית של MK לא עוזרת בפועל, אבל את התיאוריות שמנו מזמן בצד, והם לא נושא הדיון לדעתי.
 

אלדד28

New member
סבבה.

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

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

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

MotiAd

New member
I believe....

i want to implement somthing as close to as MacOSX10.... are there disadvantages about this specific imp'? are there any better for OS's that respect themselves? Yours, Moti.
 
אני לא מכיר

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

MotiAd

New member
כן אבל הנה הקאץ'...

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

אבל את הארכיטקטורה? חוץ מזה, למה אם כך אתה מחפש דווקא את הארכיטקטורה של X10? אם ל-KERNEL שאתה כותב יש בעיה לתקשר עם MICROKERNEL סינכרוני, אז פשוט חפש ארכיטקטורה שתתאים לך יותר, או שתשנה חלק מארכיטקטורת ה-KERNEL שלך. אני אישית חושב שעיצוב ה-KERNEL וה-MK צריך להיות תהליך של סימביוזה מסויימת. אתה מעצב קצת את הראשון, קצת את השני, וחוזר חלילה עד שיש לך INTERFACE טוב בין שניהם. לדוגמה, ב-MSDN וב-TECHNET מצאתי בזמנו הרבה תיעוד על הארכיטקטורה של ה-KERNEL של מערכות NT BASED. אני פשוט הנחתי, כשעניתי, שיש חומר דומה על מערכות הפעלה אחרות. יש הרבה ללמוד ממנגנוני THREAD SCHEDULING ב-NT (שד"א בשימוש גם במערכות הפעלה אחרות כמו VMS). אמנם לא ידוע לי המימוש המדוייק של המנגנון ב-MICROKERNEL של NT, אבל הרעיון שלו בהחלט מתועד היטב. המימוש, כמובן, נשאר בידיים שלך.
 

MotiAd

New member
איפה אנ יאוכל לקרוא על המימוש...

או הרעיון של תיזמון ב-NT? אני אשמח לקרוא על זה. וחוץ מזה אני לא מקובע ל-X10 אני אפילו לא הצעתי את הרעיון. רק רציתי לשאול אם יש למישהו רעיון טוב למימוש של מיקרוקרנל. או מקום נחמד שאני אוכל לקחת ממנו רעיונות ברמת התיאוריה. המימוש לא חשוב לי. ד"א איפה נמצא המימוש ב-darwin שקשור לקרנל?
 
צ'טערת

לא ראיתי ששאלת את השאלה הזו... אז כמו שאמרתי, יש המון חומר ב-TECHNET וב-MSDN. מצאתי לפחות 2 לינקים, ועוד מקור אחד ב-MSDN שמשום מה לא מופע ב-WWW. אז פשוט ציטטתי אותו. את טבלה 7.4 (חלק מהמאמר) צירפתי בנפרד. ENJOY.
Examining and Adjusting Thread Priority =========================================== Examining thread context switching and thread state gives you information about when threads in a bottleneck are being scheduled to run by the operating system and when threads are being held in the queue prior to running. Although the operating system is inherently designed to optimize the scheduling of threads, you have some control over this behavior, to adjust for situations in which scheduling behavior on your system is unsatisfactory. This section describes how you can determine a thread's scheduling priority and how you can adjust thread priority to reduce bottlenecks and allow blocked threads to run. (*) Important To ensure optimum performance on production systems, Microsoft recommends that you adjust priorities of processes first in a test environment. In addition, you should make these adjustments only if you have an in-depth understanding of priority settings and their effect on other processes and the operating system. Priority Class and Priority ============================== Under the preemptive multitasking strategy built into Windows 2000, threads and processes are assigned a priority for scheduling purposes. A thread's priority determines the order in which it is scheduled to run on the processor. A thread's priority is based on the priority class of its parent process. The four process priority classes are: Idle: Screen savers and other processes that periodically update the display typically use the Idle class. Normal: The default priority class for a process is Normal. High: Processes that run in the High priority class receive the majority of processor time. Real Time: Many kernel-mode system processes, such as those that manage mouse and keyboard input and other device operations, run in the Real Time priority class. Each process's priority class sets a range of priority values (between 1 and 31, where 1 is lowest and 31 is highest), and the threads of that process have a priority value that is within that range. (Priority 0 is reserved for system use.) If the priority class is Real Time (priorities 16 through 31), the thread's priority cannot change while the thread is running. If you have at least one priority 31 thread running, other threads cannot run. On the other hand, threads running in all other priority classes are variable, meaning that the thread's priority can change while the thread is running. For threads in the Normal or High priority classes (priorities 1 through 15), the thread's priority can be raised or lowered by up to a value of 2 but cannot fall below its original, program-defined base priority. When the base priority is adjusted to optimize scheduling, the resulting value is called the thread's dynamic priority. Table 7.4 associates each process priority class with relative thread priorities, ranked from highest priority to lowest. Notice that the highest priority class is Real Time and the lowest is Idle. Table 7.4 Process Priority Classes With Relative Thread Priorities <attached> Thread Scheduling =================== The scheduling routines of the operating system run the highest-priority ready thread uninterrupted during a quantum (also known as a time slice—the maximum amount of time a thread can run before the system checks for another ready thread of the same priority to run). If a higher-priority thread becomes ready during the quantum, the lower-priority thread is interrupted and the higher-priority thread is run. Otherwise, threads running at the same priority are scheduled in a round-robin fashion, switching among threads in order, and run until the quantum expires. In general, Windows 2000 always runs the highest-priority ready thread. However, there are optimization strategies built into the operating system to address situations in which the default scheduling methods would cause problems. The following sections describe these strategies. Foreground Process Scheduling ================================= The scheduler runs a foreground process at a higher priority, which means it tends to get more time slices than background processes. In addition, the scheduler ensures that those time slices are longer than the ones allocated to background processes. As a result, the foreground process is much more responsive than other processes because it is scheduled more often, and when it is scheduled it continues running longer before being preempted. By default, Windows 2000 Professional defines short, variable quanta for applications and gives a foreground application a priority boost. On the other hand, Windows 2000 Server has longer, fixed quanta with no priority boost for foreground applications, allowing background services to run more efficiently. To see foreground process scheduling in action, monitor the processor time for a process and move its window to the bottom of the stack. Note that the time value allocated to that process falls immediately. Then move the process to the top of the stack and note that the processor time value rises immediately. See Figure 7.18 for an illustration. Automatic Priority Boost ============================ The operating system automatically boosts the thread's priority enough for the low-priority thread to complete its operation and release the resource. After raising a thread's dynamic priority, the scheduler reduces that priority by one level each time the thread completes a time slice (quantum), until the thread drops back to its base priority.​
 
למעלה