فانغارد (نواة صغيرة)

فانغارد هو نظام تشغيل تجريبي مصغر توقف تطويره في شركة أبل للحواسيب ، ^{[ 1 ]} ضمن مجموعة أبل للتكنولوجيا المتقدمة (ATG) ذات التوجه البحثي في ​​أوائل التسعينيات. استند فانغارد إلى نظام V ، وقدم معرّفات موحدة للكائنات ونظامًا فريدًا لتسلسل الرسائل لتحسين الأداء. لم يُستخدم فانغارد في أي من منتجات أبل التجارية. توقف تطويره عام 1993 عندما غادر روس فينلايسون، الباحث الرئيسي في المشروع، شركة أبل.

كان نظام Vanguard مشابهًا إلى حد كبير لنظام V-System، ولكنه أضاف دعمًا لبرمجة كائنية التوجه حقيقية لنظام التشغيل . هذا يعني أن واجهات النواة والخادم تُصدّر ككائنات، يمكن توريثها وتوسيعها في التعليمات البرمجية الجديدة. لا يُحدث هذا التغيير أي تأثير مرئي على النظام، فهو في الأساس تغيير في التعليمات البرمجية المصدرية يُسهّل البرمجة.

على سبيل المثال، احتوى برنامج Vanguard على فئة إدخال/إخراج (I/O) مدعومة من قبل العديد من الخوادم المختلفة، مثل خوادم الشبكات وخوادم الملفات ، والتي يمكن للتطبيقات الجديدة التفاعل معها عن طريق استيراد واجهة الإدخال/الإخراج واستدعاء الدوال. وقد سهّل هذا الأمر كتابة خوادم جديدة بشكل كبير، لوجود معيار موحد للبرمجة، مما سهّل مشاركة التعليمات البرمجية.

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

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

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

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

كان أحد الإضافات الرئيسية لنظام الاتصال بين العمليات (IPC) في نظام Vanguard، على عكس نظام V، هو مفهوم سلاسل الرسائل ، الذي يسمح بإرسال رسالة واحدة بين عدة خوادم متفاعلة في جولة واحدة. من الناحية النظرية، يمكن أن يؤدي الربط بين الرسائل إلى تحسين أداء العمليات الشائعة متعددة الخطوات.

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

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

قدّم نظام V أيضًا خدمة أسماء موزعة بسيطة . خزّنت هذه الخدمة أسماءً حرفية معروفة تمثل كائنات مختلفة في نظام V الموزع، على سبيل المثال، 2nd floor laser printer. يمكن للتطبيقات طلب الكائنات من خادم الأسماء بالاسم، وستتلقى مُعرّفًا يسمح لها بالتفاعل مع ذلك الكائن. لم تكن خدمة الأسماء خادمًا منفصلاً، بل كانت تُدار بواسطة كود في نواة النظام. على النقيض من ذلك، كان خادم الأسماء الكامل في نظام التشغيل Spring على دراية بالكائنات داخل النظام، كما كان يُستخدم أيضًا من قِبل خوادم أخرى على النظام لترجمة أسمائها الخاصة، مثل أسماء الملفات وعناوين IP.

في نظام V، كان يتم الإشارة إلى الكائنات في الخوادم عبر مفتاح خاص مخصص ، كعدد صحيح 32 بت مثلاً . كانت الأجهزة العميلة تُمرر هذه المفاتيح إلى الخوادم للتواصل بشأن مهمة محددة. على سبيل المثال، قد يطلب تطبيق من نواة النظام الوصول إلى نظام الملفات ، فيُستلم مفتاح 32 بت يُمثل مُعرّف البرنامج، ثم يستخدم هذا المفتاح لإرسال رسالة إلى نظام الملفات يطلب فيها فتح الملف ، ما يُؤدي إلى استلام مفتاح 64 بت . في هذا المثال، كانت المفاتيح خاصة بالخوادم، ولم يكن هناك تنسيق مفاتيح موحد مُستخدم في جميع أنحاء النظام.my addresses

كان هذا النوع من حلّ الأسماء شائعًا جدًا في نظام V، لدرجة أن مطوري النظام قرروا جعل هذه المفاتيح أساسية في نظام Vanguard. فبدلًا من استخدام معرّفات الكائنات التي تستخدمها الخوادم عشوائيًا، كان يُتوقع من جميع الخوادم في Vanguard فهم مفتاح فريد عالميًا بطول 128 بت وإعادته ، حيث تحتوي أول 64 بت على معرّف الخادم، بينما تُعرّف البتات الـ 2 كائنًا على ذلك الخادم. يُحفظ معرّف الخادم في نواة النظام، مما يسمح لها بتمرير الرسالة عبر الشبكة إذا كان الخادم المُشار إليه موجودًا على جهاز بعيد. كان هذا غير مرئي للعميل. ولا يزال من غير الواضح ما إذا كانت المعرّفات تُعيّن عشوائيًا لمنع البرامج الخبيثة من تخمينها بنجاح.