ماخ (نواة)

Mach ( / m ɑː k / ) ^[1] هي نواة تم تطويرها في جامعة كارنيجي ميلون بواسطة ريتشارد راشد وآفي تيفانيان لدعم أبحاث أنظمة التشغيل ، الموزعة بشكل أساسي والحوسبة المتوازية . غالبًا ما يُذكر ماخ كواحد من أقدم الأمثلة على النواة الدقيقة . ومع ذلك ، ليست كل إصدارات Mach عبارة عن نواة صغيرة. مشتقات Mach هي أساس نواة نظام التشغيل في GNU Hurd ونواة Apple XNU المستخدمة في macOSو iOS و iPadOS و tvOS و watchOS .

استمر المشروع في جامعة كارنيجي ميلون من 1985 إلى 1994 ، ^[2] وانتهى بـ Mach 3.0 ، وهي نواة دقيقة حقيقية . تم تطوير Mach كبديل للنواة في إصدار BSD من Unix ، لذلك لن يتم تصميم نظام تشغيل جديد حوله. توجد Mach ومشتقاتها في عدد من أنظمة التشغيل التجارية. يتضمن ذلك جميعًا باستخدام نواة نظام التشغيل XNU التي تتضمن ماخ سابقًا غير microkernel كمكون رئيسي. تم اعتماد نظام إدارة الذاكرة الافتراضية Mach أيضًا في 4.4BSD من قبل مطوري BSD في CSRG ، ^[3] ويظهر في أنظمة Unix الحديثة المشتقة من BSD ، مثل FreeBSD.

ماخ هو الخليفة المنطقي لنواة أكسنت لكارنيجي ميلون . المطور الرئيسي في مشروع Mach ، ريتشارد راشد ، يعمل في Microsoft منذ عام 1991 ؛ أسس قسم أبحاث مايكروسوفت . كان أحد مطوري ماك الأصليين الآخرين ، آفي تيفانيان ، رئيسًا للبرامج في شركة NeXT ، ثم رئيس قسم تكنولوجيا البرمجيات في شركة Apple Inc. حتى مارس 2006. ^{[4] [2]}

التاريخ

الاسم

بينما اضطر المطورون ، مرة واحدة خلال مرحلة التسمية ، إلى ركوب الدراجة للغداء من خلال برك الطين الممطرة في بيتسبرغ ، قال تيفانيان مازحا أن كلمة "الوحل" يمكن أن تكون بمثابة اسم خلفي لـ M ulti- U ser ( أو M المعالج الفائق U العالمي ) ارنل. سأل مهندس CMU الإيطالي داريو جيوز لاحقًا قائد المشروع ريك راشد عن العنوان الحالي للمشروع وتلقى "MUCK" كإجابة ، على الرغم من عدم توضيحها ولكن تم نطقها باسم IPA:  [mʌk] الذي كتبه ، وفقًا للأبجدية الإيطالية ، باسم Mach . أحب راشد تهجئة Giuse "Mach" لدرجة أنها سادت.^{[5] : 103}

أنابيب يونكس

كان المفهوم الأساسي في نظام التشغيل الأصلي Unix هو فكرة الأنبوب . كان الأنبوب عبارة عن عملية تجريد تسمح بنقل البيانات كتدفق غير منظم من البايت من برنامج إلى آخر. باستخدام الأنابيب ، يمكن للمستخدمين (أو المبرمجين) ربط برامج متعددة معًا لإكمال المهام ، وتغذية البيانات من خلال عدة برامج صغيرة بدورها. يتناقض هذا مع أنظمة التشغيل النموذجية للعصر ، والتي كانت تتطلب برنامجًا واحدًا كبيرًا يمكنه التعامل مع المهمة بأكملها ، أو بالتناوب ، استخدم الملفات لتمرير البيانات ، والتي كانت مكلفة من حيث الموارد وتستغرق وقتًا طويلاً.

تم بناء الأنابيب على نظام الإدخال / الإخراج الأساسي . كان هذا النظام ، بدوره ، قائمًا على نموذج يُتوقع من السائقين فيه "حظر" دوريًا أثناء انتظارهم لإكمال المهام. على سبيل المثال ، قد يرسل برنامج تشغيل الطابعة سطرًا نصيًا إلى طابعة خطيةومن ثم ليس لديك ما تفعله حتى تكمل الطابعة طباعة هذا السطر. في هذه الحالة ، سيشير برنامج التشغيل إلى أنه تم حظره ، وسيسمح نظام التشغيل لبعض البرامج الأخرى بالعمل حتى تشير الطابعة إلى أنها جاهزة لمزيد من البيانات. في نظام الأنابيب ، كان المورد المحدود هو الذاكرة ، وعندما يملأ أحد البرامج الذاكرة المخصصة للأنبوب ، فإنه يتم حظره بشكل طبيعي. عادةً ما يؤدي ذلك إلى تشغيل البرنامج المستهلك ، مما يؤدي إلى تفريغ الأنبوب مرة أخرى. على عكس الملف ، حيث يجب قراءة الملف بأكمله أو كتابته قبل أن يتمكن البرنامج التالي من استخدامه ، جعلت الأنابيب حركة البيانات عبر برامج متعددة تحدث بطريقة مجزأة دون أي تدخل مبرمج.

ومع ذلك ، فإن تنفيذ الأنابيب كمخازن مؤقتة للذاكرة يعني أن البيانات يتم نسخها من برنامج إلى آخر ، وهي عملية تستغرق وقتًا طويلاً وتستهلك الكثير من الموارد. جعل هذا مفهوم الأنبوب غير مناسب للمهام التي تتطلب تحولًا سريعًا أو زمن انتقال منخفض ، كما هو الحال في معظم برامج تشغيل الأجهزة . بدلاً من ذلك تمت كتابة نواة نظام التشغيل ومعظم الوظائف الأساسية كبرنامج واحد كبير. نظرًا لأن نظام التشغيل أضاف وظائف جديدة ( شبكات الكمبيوتر ، على سبيل المثال) ، زاد حجم وتعقيد النواة أيضًا.

مفاهيم جديدة

قدمت أنابيب Unix نظامًا مفاهيميًا يمكن استخدامه لبناء حلول معقدة بشكل تعسفي من برامج تفاعلية صغيرة. نظرًا لكون هذه البرامج أصغر حجمًا ، فقد كان من السهل برمجتها وصيانتها ، ولها واجهات محددة جيدًا تعمل على تبسيط البرمجة وتصحيح الأخطاء. تعد هذه الصفات أكثر قيمة لبرامج تشغيل الأجهزة ، حيث يكون الحجم الصغير والأداء الخالي من الأخطاء في غاية الأهمية. كانت هناك رغبة قوية لنمذجة النواة نفسها على نفس الأساس لبرامج تفاعلية صغيرة.

من أوائل الأنظمة التي استخدمت نظامًا شبيهًا بالأنابيب كأساس لنظام التشغيل نواة أليف التي تم تطويرها في جامعة روتشستر . قدم هذا مفهوم المنافذ ، التي كانت في الأساس ذاكرة مشتركةالتنفيذ. في Aleph ، تم تقليص النواة نفسها لتوفير الوصول إلى الأجهزة ، بما في ذلك الذاكرة والمنافذ ، بينما نفذت البرامج التقليدية التي تستخدم نظام المنافذ كل السلوك ، من برامج تشغيل الأجهزة إلى برامج المستخدم. أدى هذا المفهوم إلى تقليل حجم النواة بشكل كبير ، وسمح للمستخدمين بتجربة برامج تشغيل مختلفة ببساطة عن طريق تحميلهم وربطهم معًا في وقت التشغيل. أدى هذا إلى تخفيف المشكلات إلى حد كبير عند تطوير رمز نظام تشغيل جديد ، والذي يتطلب بشكل عام إعادة تشغيل الجهاز. أصبح المفهوم العام للنواة الصغيرة والمحركات الخارجية يُعرف باسم النواة الصغيرة.

تم تطبيق Aleph على الحواسيب الصغيرة للكسوف العام للبيانات وكان مرتبطًا بإحكام بها. كان هذا الجهاز بعيدًا عن المثالية ، حيث تطلب ذاكرة لنسخها بين البرامج ، والتي تضمنت أداءً كبيرًا. كانت باهظة الثمن أيضًا. ومع ذلك ، أثبت "ألف" أن النظام الأساسي كان سليمًا ، واستمر في توضيح تجميع الكمبيوتر عن طريق نسخ الذاكرة عبر واجهة Ethernet مبكرة .

في هذا الوقت تقريبًا ، ظهر جيل جديد من المعالجات المركزية (وحدات المعالجة المركزية) في السوق ، مما يوفر مساحات عناوين 32 بت ودعم (اختياري في البداية) لوحدة إدارة الذاكرة (MMU). تعاملت وحدة MMU مع التعليمات اللازمة لتنفيذ نظام الذاكرة الظاهرية (VM) من خلال تتبع صفحات الذاكرة التي كانت قيد الاستخدام من قبل البرامج المختلفة. قدم هذا حلاً جديدًا لمفهوم المنفذ ، باستخدام آلية النسخ على الكتابة التي يستخدمها VM ^{[ التوضيح مطلوب ]} . بدلاً من نسخ البيانات بين البرامج ، كل ما كان يجب إرساله هو البيانات اللازمة لتوجيه MMU لتوفير الوصول إلى نفس الذاكرة. هذا النظام من شأنه أن ينفذنظام اتصالات بين العمليات بأداء أعلى بشكل كبير.

تم اختيار هذا المفهوم في Carnegie-Mellon ، الذي قام بتكييف Aleph مع محطة عمل PERQ ونفذها باستخدام النسخ عند الكتابة. كان المنفذ ناجحًا ، لكن نواة Accent الناتجة كانت ذات استخدام عملي محدود لأنها لم تقم بتشغيل البرامج الحالية. علاوة على ذلك ، كانت أكسنت مرتبطة بإحكام بـ PERQ مثل ارتباط ألف بالكسوف.

ماخ

كان التغيير الرئيسي بين هذه النواة التجريبية وماخ هو القرار بجعل نسخة من نواة 4.2BSD الحالية المعاد تنفيذها على مفاهيم تمرير الرسائل في أكسنت. سيكون مثل هذا النواة متوافقًا مع برنامج BSD الحالي ، مما يجعل النظام مفيدًا على الفور للاستخدام اليومي مع استمرار كونه منصة تجريبية مفيدة. بالإضافة إلى ذلك ، سيتم تصميم النواة الجديدة من البداية لدعم بنى المعالجات المتعددة ، حتى السماح بإنشاء مجموعات غير متجانسة. من أجل رفع مستوى النظام في أسرع وقت ممكن ، سيتم تنفيذ النظام من خلال البدء برمز BSD الحالي ، وإعادة تنفيذه شيئًا فشيئًا كتواصل بين العملياتالبرامج القائمة على IPC. وهكذا يبدأ ماخ كنظام مترابط مشابه لأنظمة UNIX الحالية ، ويتطور بشكل أكبر نحو مفهوم النواة الصغيرة بمرور الوقت. ^[4]

بدأ Mach إلى حد كبير كمحاولة لإنتاج لهجة واضحة المعالم وقائمة على UNIX وقابلة للنقل بشكل كبير. والنتيجة هي قائمة قصيرة بالمفاهيم العامة: ^{[6] [7]}

• " المهمة " هي كائن يتكون من مجموعة من موارد النظام التي تتيح تشغيل "مؤشرات الترابط"
• " الخيط " هو وحدة تنفيذ واحدة ، وهو موجود ضمن سياق مهمة ويشارك في موارد المهمة
• " المنفذ " عبارة عن قائمة انتظار رسائل محمية للاتصال بين المهام ؛ المهام الخاصة ترسل حقوق (أذونات) وتتلقى حقوق كل منفذ.
• " الرسائل " هي مجموعات من كائنات البيانات المكتوبة ، ولا يمكن إرسالها إلا إلى المنافذ - وليس المهام أو سلاسل الرسائل على وجه التحديد

تم تطوير Mach بناءً على مفاهيم IPC الخاصة بـ Accent ، ولكنه جعل النظام أكثر شبهاً بـ UNIX بطبيعته ، حتى أنه قادر على تشغيل برامج UNIX مع القليل من التعديلات أو بدون تعديل. للقيام بذلك ، قدم ماخ مفهوم المنفذ ، الذي يمثل كل نقطة نهاية لـ IPC ثنائي الاتجاه. تتمتع المنافذ بأمان وحقوق مثل الملفات الموجودة في نظام UNIX ، مما يسمح بتطبيق نموذج حماية شبيه بنظام UNIX عليها. بالإضافة إلى ذلك ، سمح Mach لأي برنامج بالتعامل مع الامتيازات التي عادةً ما تُمنح لنظام التشغيل فقط ، من أجل السماح لبرامج مساحة المستخدم بالتعامل مع أشياء مثل التفاعل مع الأجهزة.

تحت Mach ، ومثل UNIX ، يصبح نظام التشغيل مرة أخرى في الأساس مجموعة من الأدوات المساعدة. كما هو الحال مع UNIX ، يحتفظ Mach بمفهوم السائق للتعامل مع الأجهزة. لذلك ، يجب تضمين جميع برامج تشغيل الأجهزة الحالية في microkernel. يمكن للبنيات الأخرى المستندة إلى طبقة تجريد الأجهزة أو العناصر الخارجية أن تحرك السائقين خارج النواة الدقيقة.

الاختلاف الرئيسي مع UNIX هو أنه بدلاً من معالجة الملفات المساعدة ، يمكنهم التعامل مع أي "مهمة". تم نقل المزيد من كود نظام التشغيل من النواة إلى مساحة المستخدم ، مما أدى إلى نواة أصغر بكثير وظهور مصطلح microkernel . على عكس الأنظمة التقليدية ، يمكن أن تتكون العملية ، أو "المهمة" ، من عدد من الخيوط. في حين أن هذا أمر شائع في الأنظمة الحديثة ، كان Mach هو أول نظام يحدد المهام والخيوط بهذه الطريقة. تم تقليص وظيفة kernel من كونها نظام تشغيل أساسيًا إلى صيانة "المرافق" وجدولة وصولها إلى الأجهزة.

ربما يكون وجود المنافذ واستخدام IPC هو الاختلاف الأساسي بين ماخ والنواة التقليدية. تحت UNIX ، يتكون استدعاء النواة من عملية تعرف باسم استدعاء النظام أو الاعتراض . يستخدم البرنامج مكتبة لوضع البيانات في مكان معروف جيدًا في الذاكرة ثم يتسبب في حدوث خطأ ، وهو نوع من الخطأ. عند بدء تشغيل النظام لأول مرة ، يتم إعداد kernel ليكون "المعالج" لجميع الأخطاء ، لذلك عندما يتسبب البرنامج في حدوث خطأ ، تتولى النواة المسؤولية ، وتفحص المعلومات التي تم تمريرها إليها ، ثم تنفذ التعليمات.

تحت Mach ، تم استخدام نظام IPC لهذا الدور بدلاً من ذلك. من أجل استدعاء وظائف النظام ، سيطلب البرنامج من kernel الوصول إلى منفذ ، ثم يستخدم نظام IPC لإرسال رسائل إلى هذا المنفذ. على الرغم من أن الرسائل تم تشغيلها عن طريق استدعاءات النظام كما لو كانت على نواة أخرى ، إلا أنه في ظل نظام Mach كان كل ما فعلته النواة إلى حد كبير - فإن معالجة الطلب الفعلي سيكون أمرًا متروكًا لبعض البرامج الأخرى.

استفاد دعم الخيط والتزامن من خلال تمرير الرسائل مع آليات IPC نظرًا لأن المهام تتكون الآن من سلاسل تعليمات برمجية متعددة يمكن لماك تجميدها وإلغاء تجميدها أثناء معالجة الرسائل. سمح ذلك بتوزيع النظام على معالجات متعددة ، إما باستخدام الذاكرة المشتركة مباشرة كما هو الحال في معظم رسائل Mach ، أو عن طريق إضافة رمز لنسخ الرسالة إلى معالج آخر إذا لزم الأمر. هذا صعب التنفيذ في نواة تقليدية ؛ يجب أن يتأكد النظام من أن البرامج المختلفة لا تحاول الكتابة إلى نفس الذاكرة من معالجات مختلفة. ومع ذلك ، فإن منافذ Mach ، عمليتها للوصول إلى الذاكرة ، تجعل هذا محددًا جيدًا وسهل التنفيذ ، وقد أصبحت مواطنًا من الدرجة الأولى في هذا النظام.

واجه نظام IPC في البداية مشاكل في الأداء ، لذلك تم تطوير بعض الاستراتيجيات لتقليل التأثير. مثل سابقتها ، Accent ، استخدم Mach آلية ذاكرة مشتركة واحدة لتمرير الرسالة فعليًا من برنامج إلى آخر. سيكون النسخ الفعلي للرسالة بطيئًا جدًا ، لذلك يعتمد Mach على وحدة إدارة ذاكرة الجهاز (MMU) لتعيين البيانات بسرعة من برنامج إلى آخر. فقط إذا تمت كتابة البيانات ، فسيتعين نسخها فعليًا ، وهي عملية تسمى " النسخ عند الكتابة ".

تم أيضًا فحص الرسائل للتأكد من صحتها بواسطة النواة ، لتجنب تعطل البيانات السيئة لأحد البرامج العديدة التي يتكون منها النظام. تم تصميم المنافذ بشكل متعمد وفقًا لمفاهيم نظام ملفات UNIX. سمح ذلك للمستخدم بالعثور على المنافذ باستخدام مفاهيم التنقل في نظام الملفات الحالية ، بالإضافة إلى تعيين الحقوق والأذونات كما يفعلون في نظام الملفات.

سيكون التطوير في ظل مثل هذا النظام أسهل. لن يكون الرمز الذي يتم العمل عليه موجودًا فقط في برنامج تقليدي يمكن إنشاؤه باستخدام الأدوات الحالية ، بل يمكن أيضًا بدء تشغيله وتصحيحه وإيقافه باستخدام نفس الأدوات. باستخدام monokernel ، قد يؤدي الخطأ في الكود الجديد إلى تعطيل الجهاز بالكامل ويتطلب إعادة التشغيل ، بينما يتطلب ذلك إعادة تشغيل البرنامج فقط في ظل Mach. بالإضافة إلى ذلك ، يمكن للمستخدم أن يصمم النظام ليشمل أو يستبعد أي ميزات يحتاجها. نظرًا لأن نظام التشغيل كان مجرد مجموعة من البرامج ، فيمكنهم إضافة أجزاء أو إزالتها ببساطة عن طريق تشغيلها أو قتلها كما يفعل أي برنامج آخر.

أخيرًا ، في ظل نظام Mach ، تم تصميم كل هذه الميزات عن عمد لتكون منصة محايدة للغاية. لاقتباس نص واحد على ماخ:

على عكس UNIX ، الذي تم تطويره دون اعتبار للمعالجة المتعددة ، فإن Mach يدمج دعم المعالجة المتعددة طوال الوقت. كما أن دعم المعالجة المتعددة الخاص به مرن للغاية ، بدءًا من أنظمة الذاكرة المشتركة إلى الأنظمة التي لا تحتوي على ذاكرة مشتركة بين المعالجات. تم تصميم Mach ليعمل على أنظمة كمبيوتر تتراوح من واحد إلى آلاف المعالجات. بالإضافة إلى ذلك ، يتم نقل Mach بسهولة إلى العديد من هياكل الكمبيوتر المتنوعة. الهدف الرئيسي لماخ هو أن يكون نظامًا موزعًا قادرًا على العمل على أجهزة غير متجانسة. ^[8]

ومع ذلك ، هناك عدد من العيوب. ومن الأمور العادية نسبيًا أنه ليس من الواضح كيفية العثور على المنافذ. في ظل نظام UNIX ، تم حل هذه المشكلة بمرور الوقت حيث وافق المبرمجون على عدد من المواقع "المعروفة" في نظام الملفات لخدمة الواجبات المختلفة. في حين أن هذا النهج نفسه يعمل مع منافذ Mach أيضًا ، فقد كان من المفترض أن يكون نظام التشغيل أكثر مرونة في نظام Mach ، حيث تظهر المنافذ وتختفي طوال الوقت. بدون وجود آلية معينة للعثور على الموانئ والخدمات التي تمثلها ، سيتم فقد الكثير من هذه المرونة.

تطوير

تمت استضافة Mach في البداية كرمز إضافي مكتوب مباشرة في نواة 4.2BSD الحالية ، مما يسمح للفريق بالعمل على النظام قبل وقت طويل من اكتماله. بدأ العمل بنظام Accent IPC / port الذي يعمل بالفعل ، وانتقل إلى الأجزاء الرئيسية الأخرى من نظام التشغيل والمهام والخيوط والذاكرة الافتراضية. مع اكتمال الأجزاء ، تمت إعادة كتابة أجزاء مختلفة من نظام BSD لاستدعاء Mach ، كما تم إجراء تغيير إلى 4.3BSD أثناء هذه العملية.

بحلول عام 1986 ، كان النظام قد اكتمل لدرجة أنه أصبح قادرًا على العمل بمفرده على DEC VAX . على الرغم من عدم القيام سوى بالقليل من القيمة العملية ، فقد تم تحقيق الهدف المتمثل في صنع نواة صغيرة. وسرعان ما تبع ذلك إصدارات على كمبيوتر IBM RT ومحطات عمل قائمة على Sun Microsystems 68030 ، مما يثبت قابلية النظام للتنقل. بحلول عام 1987 ، تضمنت القائمة آلات Encore Multimax و Sequent Balance ، لاختبار قدرة Mach على العمل على أنظمة متعددة المعالجات. تم إصدار الإصدار 1 العام في ذلك العام ، وتبع الإصدار 2 العام التالي.

طوال هذا الوقت ، لم يتم تسليم الوعد بنواة "حقيقية". تضمنت إصدارات Mach المبكرة هذه غالبية 4.3BSD في النواة ، وهو نظام يُعرف باسم خادم POE ، مما أدى إلى نواة كانت في الواقع أكبر من UNIX التي كانت تستند إليها. كانت الفكرة ، مع ذلك ، هي نقل طبقة UNIX من النواة إلى مساحة المستخدم ، حيث يمكن العمل عليها بسهولة أكبر وحتى استبدالها تمامًا. لسوء الحظ ، ثبت أن الأداء يمثل مشكلة كبيرة ، وتم إجراء عدد من التغييرات المعمارية من أجل حل هذه المشكلة. كانت مشكلات ترخيص UNIX غير العملية تزعج الباحثين أيضًا ، لذلك استمر هذا الجهد المبكر لتوفير بيئة نظام شبيهة بـ UNIX غير مرخصة في الاستخدام ، وكذلك في التطوير الإضافي لـ Mach.

تم إصدار Mach 3 الناتج في عام 1990 ، وأثار اهتمامًا شديدًا. قام فريق صغير ببناء Mach ونقله إلى عدد من المنصات ، بما في ذلك الأنظمة المعقدة متعددة المعالجات التي تسببت في مشاكل خطيرة للنواة القديمة. ولّد هذا اهتمامًا كبيرًا بالسوق التجاري ، حيث كان عدد من الشركات في خضم التفكير في تغيير منصات الأجهزة. إذا كان من الممكن تشغيل النظام الحالي ليعمل على Mach ، فيبدو أنه سيكون من السهل تغيير النظام الأساسي الموجود تحته.

تلقى Mach دفعة كبيرة في الرؤية عندما أعلنت مؤسسة Open Software Foundation (OSF) أنها ستستضيف الإصدارات المستقبلية من OSF / 1 على Mach 2.5 ، وكانت تحقق في Mach 3 أيضًا. تم اختيار Mach 2.5 أيضًا لنظام NeXTSTEP وعدد من البائعين التجاريين متعددي المعالجات. أدى Mach 3 إلى عدد من الجهود لنقل أجزاء أنظمة تشغيل أخرى لـ microkernel ، بما في ذلك نظام التشغيل Workplace OS الخاص بشركة IBM والجهود العديدة التي بذلتها Apple لإنشاء إصدار متعدد الأنظمة الأساسية لنظام التشغيل Mac OS الكلاسيكي . ^[9]

مشاكل الأداء

كان من المفترض في الأصل أن يكون Mach بديلاً عن نظام UNIX الكلاسيكي المتآلف ، ولهذا السبب احتوى على العديد من الأفكار المشابهة لـ UNIX. على سبيل المثال ، استخدم Mach نظام إذن وأمن منقوش على نظام ملفات UNIX. نظرًا لأن kernel كان يتمتع بامتياز (يعمل في مساحة kernel ) على خوادم وبرامج نظام التشغيل الأخرى ، فقد كان من الممكن للبرامج المعطلة أو الخبيثة إرسال أوامر من شأنها أن تتسبب في إتلاف النظام ، ولهذا السبب قامت kernel بفحص كل رسالة للتأكد من صحتها . بالإضافة إلى ذلك ، كان من المقرر وضع معظم وظائف نظام التشغيل في برامج مساحة المستخدم ، لذلك كان هذا يعني أن هناك حاجة إلى وجود طريقة ما كي تمنح النواة هذه البرامج امتيازات إضافية ، للعمل على الأجهزة على سبيل المثال.

استندت بعض ميزات Mach الأكثر سرية أيضًا إلى آلية IPC نفسها. على سبيل المثال ، كان Mach قادرًا على دعم الأجهزة متعددة المعالجات بسهولة. في النواة التقليدية ، يجب تنفيذ عمل مكثف لجعله قابلًا للدخول أو الانقطاع، حيث يمكن للبرامج التي تعمل على معالجات مختلفة استدعاء النواة في نفس الوقت. في إطار Mach ، يتم عزل أجزاء نظام التشغيل في الخوادم ، والتي يمكن تشغيلها ، مثل أي برنامج آخر ، على أي معالج. على الرغم من أنه من الناحية النظرية ، يجب أيضًا إعادة إدخال نواة Mach ، إلا أن هذه ليست مشكلة من الناحية العملية لأن أوقات استجابتها سريعة جدًا بحيث يمكنها ببساطة الانتظار وخدمة الطلبات بدورها. تضمن Mach أيضًا خادمًا يمكنه إعادة توجيه الرسائل ليس فقط بين البرامج ، ولكن حتى عبر الشبكة ، والتي كانت منطقة تطور مكثف في أواخر الثمانينيات وأوائل التسعينيات.

لسوء الحظ ، تبين أن استخدام IPC لجميع المهام تقريبًا له تأثير خطير على الأداء. أظهرت المعايير على أجهزة 1997 أن تطبيقات UNIX التي تستند إلى Mach 3.0 على الخادم الفردي كانت أبطأ بنحو 50٪ من UNIX الأصلي. ^{[10] [11]}

كشفت دراسة الطبيعة الدقيقة لمشاكل الأداء عن عدد من الحقائق المثيرة للاهتمام. أحدها هو أن IPC نفسه لم يكن هو المشكلة: كان هناك بعض النفقات العامة المرتبطة بتعيين الذاكرة اللازمة لدعمها ، لكن هذا أضاف مقدارًا صغيرًا من الوقت لإجراء مكالمة. الباقي ، 80٪ من الوقت الذي يتم إنفاقه ، كان بسبب مهام إضافية كانت النواة تعمل على الرسائل. من بين هذه العناصر الأساسية التحقق من حقوق المنفذ وصلاحية الرسالة. في المعايير على 486 DX-50 ، استغرقت مكالمة نظام UNIX القياسية 21 ميكروثانية في المتوسط ​​لإكمالها ، بينما بلغ متوسط ​​العملية المكافئة مع Mach IPC 114μs. 18μs فقط من هذا كانت متعلقة بالأجهزة ؛ كان الباقي هو Mach kernel الذي يدير إجراءات مختلفة على الرسالة. ^[12]بالنظر إلى نظام مكالمات النظام الذي لا يفعل شيئًا ، فإن الرحلة الكاملة ذهابًا وإيابًا في إطار BSD تتطلب حوالي 40 ميكرو ثانية ، بينما في نظام ماك لمساحة المستخدم ، سيستغرق الأمر أقل من 500 ميكرو ثانية.

عندما تم استخدام Mach لأول مرة بجدية في إصدارات 2.x ، كان الأداء أبطأ من أنظمة التشغيل التقليدية المتجانسة ، ربما بنسبة تصل إلى 25٪. ^[1] لم تكن هذه التكلفة مقلقة بشكل خاص ، لأن النظام كان يوفر أيضًا دعمًا متعدد المعالجات وسهولة النقل. شعر الكثير أن هذه تكلفة متوقعة ومقبولة للدفع. عندما حاولت Mach 3 نقل معظم نظام التشغيل إلى مساحة المستخدم ، أصبح الحمل أعلى: أظهرت المعايير بين Mach و Ultrix على MIPS R3000 أداءً يصل إلى 67٪ في بعض أعباء العمل. ^[13]

على سبيل المثال ، يتضمن الحصول على وقت النظام استدعاء IPC لخادم مساحة المستخدم الذي يحافظ على ساعة النظام . يقوم المتصل أولاً بالتعويض في النواة ، مما يتسبب في تبديل السياق وتعيين الذاكرة. تتحقق النواة بعد ذلك من أن المتصل لديه حقوق وصول مطلوبة وأن الرسالة صالحة. إذا كان الأمر كذلك ، فهناك تبديل سياق آخر وتعيين ذاكرة لإكمال المكالمة إلى خادم مساحة المستخدم. يجب بعد ذلك تكرار العملية لإرجاع النتائج ، مع إضافة ما يصل إلى أربعة مفاتيح سياق وتعيينات للذاكرة ، بالإضافة إلى عمليتي تحقق من الرسالة. يتراكم هذا الحمل بسرعة مع الخدمات الأكثر تعقيدًا ، حيث توجد غالبًا مسارات رمز تمر عبر العديد من الخوادم.

لم يكن هذا هو المصدر الوحيد لمشاكل الأداء. ركز آخر على مشاكل محاولة التعامل مع الذاكرة بشكل صحيح عندما تنخفض الذاكرة الفعلية وحدث الترحيل. في أنظمة التشغيل التقليدية المتجانسة ، كان للمؤلفين خبرة مباشرة في تحديد أجزاء النواة التي يطلق عليها الآخرون ، مما يسمح لهم بضبط جهاز النداء الخاص بهم لتجنب الشفرة التي كانت على وشك استخدامها. لم يكن هذا ممكنًا تحت ماخ لأن النواة لم يكن لديها فكرة حقيقية عما يتكون منه نظام التشغيل. بدلاً من ذلك ، كان عليهم استخدام حل واحد يناسب الجميع يضيف إلى مشاكل الأداء. حاول Mach 3 معالجة هذه المشكلة من خلال توفير بيجر بسيط ، بالاعتماد على أجهزة الاستدعاء في مساحة المستخدم للحصول على تخصص أفضل. لكن تبين أن هذا ليس له تأثير يذكر. في التمرين،

كانت مشاكل الأداء الأخرى مرتبطة بدعم Mach للأنظمة متعددة المعالجات . من منتصف الثمانينيات إلى أوائل التسعينيات ، نما أداء وحدات المعالجة المركزية السلعية بمعدل حوالي 60٪ سنويًا ، لكن سرعة الوصول إلى الذاكرة نمت بنسبة 7٪ فقط سنويًا. هذا يعني أن تكلفة الوصول إلى الذاكرة نمت بشكل كبير خلال هذه الفترة ، وبما أن Mach كان يعتمد على تخطيط الذاكرة بين البرامج ، فإن أي "خطأ في ذاكرة التخزين المؤقت" يجعل مكالمات IPC بطيئة.

الحلول المحتملة

النفقات العامة IPC هي قضية رئيسية لأنظمة Mach 3. ومع ذلك ، لا يزال مفهوم نظام التشغيل متعدد الخوادم واعدًا ، على الرغم من أنه لا يزال يتطلب بعض البحث. يجب على المطورين توخي الحذر لعزل التعليمات البرمجية في وحدات نمطية لا تستدعي من خادم إلى خادم. على سبيل المثال ، سيتم وضع غالبية رمز الشبكة في خادم واحد ، وبالتالي تقليل IPC لمهام الشبكات العادية.

تمسك معظم المطورين بدلاً من ذلك بمفهوم POE الأصلي لخادم كبير واحد يوفر وظائف نظام التشغيل. ^[14] من أجل تسهيل التطوير ، سمحوا لخادم نظام التشغيل بالعمل إما في مساحة المستخدم أو مساحة النواة. سمح لهم ذلك بالتطوير في مساحة المستخدم والحصول على جميع مزايا فكرة Mach الأصلية ، ثم نقل الخادم الذي تم تصحيحه إلى مساحة kernel من أجل الحصول على أداء أفضل. منذ ذلك الحين تم إنشاء العديد من أنظمة التشغيل باستخدام هذه الطريقة ، والمعروفة باسم الموقع المشترك ، من بينها Lites و MkLinux و OSF / 1 و NeXTSTEP / OPENSTEP / macOS. النواة الصغيرة للجوقةجعل هذه ميزة للنظام الأساسي ، مما يسمح للخوادم بالارتقاء إلى مساحة النواة باستخدام آليات مدمجة.

حاول Mach 4 معالجة هذه المشاكل ، هذه المرة بمجموعة أكثر جذرية من الترقيات. على وجه الخصوص ، تم العثور على أن رمز البرنامج لم يكن قابلاً للكتابة عادةً ، لذلك كانت الزيارات المحتملة بسبب النسخ عند الكتابة نادرة. وبالتالي ، فمن المنطقي عدم تعيين الذاكرة بين البرامج لـ IPC ، ولكن بدلاً من ذلك يتم ترحيل رمز البرنامج المستخدم إلى المساحة المحلية للبرنامج. أدى هذا إلى مفهوم "المكوكات" ويبدو أن الأداء قد تحسن ، لكن المطورين انتقلوا إلى النظام في حالة شبه قابلة للاستخدام. قدم Mach 4 أيضًا بدائل الموقع المشترك المضمنة ، مما يجعله جزءًا من النواة نفسها.

بحلول منتصف التسعينيات ، كان العمل على أنظمة microkernel راكدًا إلى حد كبير ، على الرغم من أن السوق كان يعتقد عمومًا أن جميع أنظمة التشغيل الحديثة سوف تعتمد على microkernel بحلول التسعينيات. الاستخدامات الأساسية المتبقية على نطاق واسع لـ Mach kernel هي macOS من Apple وشقيقها iOS ، والتي تعمل على أساس هجين معدّل بشكل كبير Open Software Foundation Mach Kernel (OSFMK 7.3) تسمى " XNU " ^[15] المستخدمة أيضًا في OSF / 1 . ^[9] في XNU ، يتم تنفيذ أنظمة الملفات ، وحزم الشبكات ، ووظائف إدارة العمليات والذاكرة في النواة ؛ ويتم استدعاء نظام الملفات والشبكات وبعض وظائف إدارة العمليات والذاكرة من وضع المستخدم عبر مكالمات النظام العاديةبدلاً من تمرير الرسائل ؛ ^{[16] [17]} تُستخدم رسائل Mach الخاصة بـ XNU للاتصال بين عمليات وضع المستخدم ، وللبعض الطلبات من كود وضع المستخدم إلى النواة ومن النواة إلى خوادم وضع المستخدم.

النواة الدقيقة من الجيل الثاني

أظهر التحليل الإضافي أن مشكلة أداء التصنيف الدولي للبراءات لم تكن واضحة كما تبدو. تذكر أن جانبًا واحدًا من مكالمة النظام استغرق 20 ميكرو ثانية تحت BSD ^[3] و 114 ميكرو ثانية على ماخ يعمل على نفس النظام. ^[2] من أصل 114 ، كان 11 بسبب تبديل السياق ، المتطابق مع BSD. ^[11] تم استخدام 18 إضافية بواسطة MMU لتعيين الرسالة بين مساحة المستخدم وفضاء النواة. ^[3] هذا يضيف ما يصل إلى 29μs فقط ، أطول من syscall التقليدي ، ولكن ليس كثيرًا.

الباقي ، غالبية المشكلة الفعلية ، كان بسبب أداء النواة لمهام مثل التحقق من الرسالة الخاصة بحقوق الوصول إلى المنفذ. ^[5] بينما يبدو أن هذا يمثل مصدر قلق أمني مهم ، إلا أنه في الواقع يكون منطقيًا فقط في نظام يشبه UNIX. على سبيل المثال ، قد لا يحتاج نظام التشغيل المستخدم الفردي الذي يشغل هاتفًا خلويًا أو روبوتًا إلى أي من هذه الميزات ، وهذا هو بالضبط نوع النظام الذي يكون فيه نظام التشغيل الخاص بـ Mach للاختيار والاختيار أكثر قيمة. وبالمثل ، تسبب ماخ في مشاكل عندما تم نقل الذاكرة بواسطة نظام التشغيل ، وهي مهمة أخرى لا تكون منطقية إلا إذا كان النظام يحتوي على أكثر من مساحة عنوان واحدة. يحتوي DOS و Mac OS المبكر على مساحة عنوان واحدة كبيرةمشتركة من قبل جميع البرامج ، لذلك في ظل هذه الأنظمة لم تقدم الخرائط أي فوائد.

أدت هذه الإدراكات إلى سلسلة من النوى الدقيقة من الجيل الثاني ، مما قلل من تعقيد النظام ووضع جميع الوظائف تقريبًا في مساحة المستخدم. على سبيل المثال ، تشتمل نواة L4 (الإصدار 2) على سبعة مكالمات فقط للنظام وتستخدم 12 كيلو بايت من الذاكرة ، ^[3] بينما تشتمل Mach 3 على حوالي 140 وظيفة وتستخدم حوالي 330 كيلو بايت من الذاكرة. ^[3] مكالمات IPC تحت L4 على 486DX-50 تستغرق 5μs فقط ، ^[17] أسرع من UNIX syscall على نفس النظام ، وأكثر من 20 مرة أسرع من Mach. بالطبع هذا يتجاهل حقيقة أن L4 لا تتعامل مع الإذن أو الأمان ؛ ولكن من خلال ترك هذا لبرامج مساحة المستخدم ، يمكنهم تحديد الكثير أو القليل من النفقات العامة التي يحتاجون إليها.

يتم تخفيف مكاسب الأداء المحتملة لـ L4 من خلال حقيقة أن تطبيقات مساحة المستخدم ستضطر في كثير من الأحيان إلى توفير العديد من الوظائف التي كانت تدعمها النواة سابقًا. من أجل اختبار الأداء الشامل ، تمت مقارنة MkLinux في الوضع المشترك مع منفذ L4 يعمل في مساحة المستخدم. أضاف L4 حوالي 5٪ -10٪ النفقات العامة ، ^[11] مقارنة بماخ 29٪. ^[11]

برنامج يعتمد على Mach

فيما يلي قائمة بنواة نظام التشغيل المشتقة من Mach وأنظمة التشغيل ذات النواة المشتقة من Mach:

انظر أيضا

• نواة
• عائلة L4 microkernel
• عائلة إيروس microkernel
• MERT

المراجع

روابط خارجية

• الموقع الرسمي ، صفحة ماخ الرئيسية لمشروع علوم الكمبيوتر بجامعة كارنيجي ميلون
• نظام ماخ  - ملحق لمفاهيم نظام التشغيل (الطبعة الثامنة) بقلم آفي سيلبيرشاتز وبيتر باير جالفين وجريج جاني
• مقارنة بين ماخ وأميبا وجوقة
• نحو النوى الدقيقة الحقيقية  - يحتوي على العديد من قياسات الأداء ، بما في ذلك تلك المقتبسة في المقالة
• أداء الأنظمة المستندة إلى µ-Kernel  - يحتوي على مقارنة أداء ممتازة بين Linux الذي يعمل كنواة أحادية ، على Mach 3 و L4
• شفرة مصدر Mach kernel - نسخة قابلة للتصفح من شفرة مصدر Mach Kernel على موقع الإسناد التبادلي لـ FreeBSD / Linux kernel
• كشف أسطورة Mac OS X Microkernel