النواة الدقيقة

الموسوعة الحرة

بنية أنظمة التشغيل المتجانسة والقائمة على النواة الدقيقة على التوالي

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

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

من حيث حجم الكود المصدري، غالبًا ما تكون النوى الدقيقة أصغر من النوى المتجانسة . على سبيل المثال، تحتوي نواة MINIX 3 الدقيقة على ما يقرب من 12000 سطر من الكود فقط. [2]

تاريخ

تعود جذور النوى الدقيقة إلى رائد الكمبيوتر الدنماركي بير برينش هانسن وفترة عمله في شركة الكمبيوتر الدنماركية Regnecentralen حيث قاد جهود تطوير البرامج لجهاز الكمبيوتر RC 4000. [3] في عام 1967، كانت شركة Regnecentralen تقوم بتثبيت نموذج أولي لجهاز RC 4000 في مصنع الأسمدة Zakłady Azotowe Puławy في بولندا. استخدم الكمبيوتر نظام تشغيل صغيرًا في الوقت الفعلي مصممًا لتلبية احتياجات المصنع. أصبح برينش هانسن وفريقه قلقين بشأن الافتقار إلى العمومية وإعادة استخدام نظام RC 4000. لقد خشوا أن يتطلب كل تثبيت نظام تشغيل مختلفًا، لذلك بدأوا في التحقيق في طرق جديدة وأكثر عمومية لإنشاء برامج لجهاز RC 4000. [4] في عام 1969، أسفرت جهودهم عن إكمال نظام RC 4000 متعدد البرمجة . كان جوهرها يوفر اتصالاً بين العمليات بناءً على تمرير الرسائل لما يصل إلى 23 عملية غير مخولة، منها 8 عمليات محمية من بعضها البعض في كل مرة. كما نفذت جدولة شرائح زمنية للبرامج التي يتم تنفيذها بالتوازي، وبدء تشغيل البرنامج والتحكم في تنفيذه بناءً على طلب برامج أخرى قيد التشغيل، وبدء نقل البيانات من وإلى الأجهزة الطرفية. وبجانب هذه الآليات الأولية، لم يكن لديها استراتيجية مدمجة لتنفيذ البرنامج وتخصيص الموارد. كان من المقرر تنفيذ هذه الاستراتيجية من خلال تسلسل هرمي من البرامج قيد التشغيل حيث تتمتع العمليات الأساسية بالسيطرة الكاملة على العمليات الفرعية وتعمل كأنظمة تشغيل لها. [5] [6]

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

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

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

بُذلت محاولات عديدة لتكييف الأنظمة الحالية لتحقيق أداء أفضل، لكن التكلفة كانت كبيرة دائمًا وكانت معظم هذه الجهود تتطلب نقل برامج مساحة المستخدم مرة أخرى إلى النواة. بحلول عام 2000، انتهت معظم جهود نواة Mach واسعة النطاق، على الرغم من أن نظام التشغيل macOS من Apple ، الذي تم إصداره في عام 2001، لا يزال يستخدم نواة هجينة تسمى XNU ، والتي تجمع بين نواة Mach المعدلة بشدة (الهجينة) OSF/1 ( نواة OSFMK 7.3) مع كود من BSD UNIX، [11] [12] وتُستخدم هذه النواة أيضًا في iOS و tvOS و watchOS . يستخدم Windows NT ، بدءًا من NT 3.1 واستمرارًا مع Windows 11 ، تصميم نواة هجين. اعتبارًا من عام 2012 ، أصبح GNU Hurd المستند إلى Mach وظيفيًا أيضًا ومضمنًا في إصدارات اختبار Arch Linux و Debian .

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

ترتبط النوى الدقيقة ارتباطًا وثيقًا بالنوى الخارجية . [13] كما أن لديها الكثير من القواسم المشتركة مع المشرفين الافتراضيين ، [14] ولكن الأخير لا يدعي الحد الأدنى ويتخصص في دعم الآلات الافتراضية ؛ غالبًا ما يتم استخدام النواة الدقيقة L4 في سعة المشرف الافتراضي.

مقدمة

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

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

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

التواصل بين العمليات

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

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

تدعم نوى الجيل الأول عادةً الاتصال بين المعالجات المتزامن وغير المتزامن، كما عانت من ضعف أداء الاتصال بين المعالجات. افترض يوشين ليدتك أن تصميم وتنفيذ آليات الاتصال بين المعالجات هو السبب الأساسي وراء هذا الأداء الضعيف. في نواة L4 الخاصة به ، كان رائدًا في الأساليب التي خفضت تكاليف الاتصال بين المعالجات بمقدار كبير . [15] تتضمن هذه نداء نظام الاتصال بين المعالجات الذي يدعم عملية الإرسال وكذلك عملية الاستقبال، مما يجعل جميع الاتصالات بين المعالجات متزامنة، وتمرير أكبر قدر ممكن من البيانات في السجلات. علاوة على ذلك، قدم ليدتك مفهوم تبديل العملية المباشرة ، حيث يتم أثناء تنفيذ الاتصال بين المعالجات إجراء تبديل سياق (غير مكتمل) من المرسل مباشرة إلى المستقبل. إذا تم تمرير جزء من الرسالة أو كلها في السجلات، كما هو الحال في L4، فإن هذا ينقل الجزء الموجود في السجل من الرسالة دون أي نسخ على الإطلاق. علاوة على ذلك، يتم تجنب التكلفة الإضافية لاستدعاء المجدول؛ هذا مفيد بشكل خاص في الحالة الشائعة حيث يتم استخدام IPC في نمط استدعاء الإجراء عن بعد (RPC) بواسطة عميل يستدعي خادمًا. يتجنب تحسين آخر، يسمى الجدولة الكسولة ، عبور قوائم انتظار الجدولة أثناء IPC من خلال ترك الخيوط التي يتم حظرها أثناء IPC في قائمة الانتظار الجاهزة. بمجرد استدعاء المجدول، فإنه ينقل مثل هذه الخيوط إلى قائمة الانتظار المناسبة. كما هو الحال في العديد من الحالات، يتم إلغاء حظر الخيط قبل استدعاء المجدول التالي، يوفر هذا النهج قدرًا كبيرًا من العمل. تم تبني طرق مماثلة منذ ذلك الحين بواسطة QNX و MINIX 3. [ بحاجة لمصدر ]

في سلسلة من التجارب، قارن تشين وبيرشاد دورات الذاكرة لكل تعليمة (MCPI) لـ Ultrix المتجانس مع دورات Mach ذات النواة الدقيقة جنبًا إلى جنب مع خادم Unix 4.3BSD يعمل في مساحة المستخدم . أوضحت نتائجهم الأداء الأضعف لـ Mach من خلال MCPI الأعلى وأظهرت أن IPC وحده ليس مسؤولاً عن الكثير من النفقات العامة للنظام، مما يشير إلى أن التحسينات التي تركز حصريًا على IPC سيكون لها تأثير محدود. [16] قام Liedtke لاحقًا بتحسين نتائج Chen وBershad من خلال إجراء ملاحظة مفادها أن الجزء الأكبر من الاختلاف بين Ultrix وMach MCPI كان ناتجًا عن أخطاء ذاكرة التخزين المؤقت للسعة واستنتاج أن تقليل مجموعة عمل ذاكرة التخزين المؤقت لنواة دقيقة بشكل كبير سيحل المشكلة. [17]

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

نظرًا لأن IPC المتزامن يحظر الطرف الأول حتى يصبح الطرف الآخر جاهزًا، فقد يؤدي الاستخدام غير المقيد بسهولة إلى طريق مسدود. علاوة على ذلك، يمكن للعميل بسهولة شن هجوم رفض الخدمة على الخادم عن طريق إرسال طلب وعدم محاولة تلقي الرد مطلقًا. لذلك، يجب أن يوفر IPC المتزامن وسيلة لمنع الحظر غير المحدود. توفر العديد من النوى الصغيرة مهلة زمنية على مكالمات IPC، والتي تحد من وقت الحظر. في الممارسة العملية، يعد اختيار قيم مهلة زمنية معقولة أمرًا صعبًا، وتستخدم الأنظمة بشكل حتمي تقريبًا مهلة زمنية غير محدودة للعملاء ومهلة زمنية صفرية للخوادم. نتيجة لذلك، يتجه الاتجاه نحو عدم توفير مهلة زمنية عشوائية، ولكن فقط علامة تشير إلى أن IPC يجب أن تفشل على الفور إذا لم يكن الشريك جاهزًا. يوفر هذا النهج فعليًا اختيار قيمتي مهلة زمنية صفرية ولا نهائية. اتبعت الإصدارات الأخيرة من L4 وMINIX هذا المسار (استخدمت الإصدارات الأقدم من L4 مهلة زمنية). يتجنب QNX المشكلة من خلال مطالبة العميل بتحديد مخزن الرد كجزء من مكالمة إرسال الرسالة. عندما يرد الخادم، تقوم النواة بنسخ البيانات إلى مخزن العميل، دون الحاجة إلى انتظار العميل لتلقي الاستجابة صراحةً. [19]

الخوادم

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

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

بالإضافة إلى ذلك، يمكن تصحيح العديد من "الأعطال" ببساطة عن طريق إيقاف الخادم وإعادة تشغيله . ومع ذلك، يتم فقد جزء من حالة النظام مع الخادم الفاشل، وبالتالي فإن هذا النهج يتطلب من التطبيقات التعامل مع الفشل. ومن الأمثلة الجيدة على ذلك الخادم المسؤول عن اتصالات TCP/IP : إذا أعيد تشغيل هذا الخادم، فستواجه التطبيقات "اتصالاً مفقودًا"، وهو أمر طبيعي في نظام شبكي. بالنسبة للخدمات الأخرى، يكون الفشل أقل توقعًا وقد يتطلب إجراء تغييرات على كود التطبيق. بالنسبة لـ QNX، يتم تقديم إمكانية إعادة التشغيل كمجموعة أدوات QNX High Availability Toolkit. [20]

برامج تشغيل الجهاز

غالبًا ما تقوم برامج تشغيل الأجهزة بإجراء وصول مباشر إلى الذاكرة (DMA)، وبالتالي يمكنها الكتابة إلى مواقع عشوائية من الذاكرة الفعلية، بما في ذلك هياكل بيانات النواة المختلفة. لذلك يجب أن تكون مثل هذه البرامج موثوقة. ومن المفاهيم الخاطئة الشائعة أن هذا يعني أنها يجب أن تكون جزءًا من النواة. في الواقع، لا يكون برنامج التشغيل أكثر أو أقل جدارة بالثقة بطبيعته من خلال كونه جزءًا من النواة.

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

في الواقع، سبقت برامج تشغيل وضع المستخدم النوى الدقيقة. ففي عام 1967، دعم نظام محطة ميشيغان (MTS) برامج تشغيل مساحة المستخدم (بما في ذلك دعم نظام الملفات الخاص به)، وهو أول نظام تشغيل تم تصميمه بهذه القدرة. [22] تاريخيًا، كانت برامج التشغيل أقل مشكلة، حيث كان عدد الأجهزة صغيرًا وموثوقًا به على أي حال، لذا فإن وجودها في النواة أدى إلى تبسيط التصميم وتجنب مشاكل الأداء المحتملة. وقد أدى هذا إلى نمط برنامج التشغيل التقليدي في النواة في يونكس [23] ولينكس وويندوز إن تي. ومع انتشار أنواع مختلفة من الأجهزة الطرفية، تصاعدت كمية كود برنامج التشغيل وفي أنظمة التشغيل الحديثة تهيمن على النواة في حجم الكود.

المكونات الأساسية والحد الأدنى

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

كان هذا التصميم البسيط رائدًا من قبل Nucleus لـ Brinch Hansen وبرنامج التشغيل الافتراضي لـ VM الخاص بـ IBM . ومنذ ذلك الحين تم إضفاء الطابع الرسمي عليه في مبدأ الحد الأدنى لـ Liedtke :

لا يتم التسامح مع المفهوم داخل النواة الدقيقة إلا إذا كان نقله خارج النواة، أي السماح بالتطبيقات المتنافسة، من شأنه أن يمنع تنفيذ الوظائف المطلوبة للنظام. [17]

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

يرتبط بمبدأ الحد الأدنى، وهو مهم بنفس القدر لتصميم النواة الدقيقة، الفصل بين الآلية والسياسة ، وهو ما يمكّن من بناء أنظمة عشوائية أعلى نواة بسيطة. لا يمكن استبدال أي سياسة مضمنة في النواة على مستوى المستخدم وبالتالي تحد من عمومية النواة الدقيقة. [13] يمكن تغيير السياسة المطبقة في خوادم مستوى المستخدم عن طريق استبدال الخوادم (أو السماح للتطبيق بالاختيار بين الخوادم المتنافسة التي تقدم خدمات مماثلة).

من أجل تحقيق الكفاءة، تحتوي معظم النوى الصغيرة على جداول زمنية وتدير مؤقتات، في انتهاك لمبدأ الحد الأدنى ومبدأ الفصل بين السياسة والآلية.

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

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

أداء

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

لذلك فإن الأداء يمثل مشكلة محتملة في أنظمة النواة الدقيقة. فقد أظهرت تجربة أنوية الجيل الأول مثل Mach و ChorusOS أن الأنظمة القائمة عليها كان أداؤها سيئًا للغاية. [16] ومع ذلك، أظهر Jochen Liedtke أن مشاكل أداء Mach كانت نتيجة لتصميم وتنفيذ سيئين، وتحديدًا بصمة ذاكرة التخزين المؤقت المفرطة لـ Mach . [17] أظهر Liedtke باستخدام نواة L4 الدقيقة الخاصة به أنه من خلال التصميم والتنفيذ الدقيقين، وخاصة باتباع مبدأ الحد الأدنى، يمكن تقليل تكاليف IPC بأكثر من مرتبة من حيث الحجم مقارنة بـ Mach. لا يزال أداء IPC الخاص بـ L4 لا يُهزم عبر مجموعة من البنيات. [24] [25] [26]

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

يوجد عدد من أنظمة الخوادم المتعددة التجارية، وخاصة أنظمة الوقت الحقيقي QNX و Integrity . لم يتم نشر مقارنة شاملة للأداء بالنسبة للأنظمة المتجانسة لتلك الأنظمة متعددة الخوادم. علاوة على ذلك، لا يبدو أن الأداء هو الشغل الشاغل لتلك الأنظمة التجارية، والتي تؤكد بدلاً من ذلك على أوقات الاستجابة السريعة والموثوقة للتعامل مع المقاطعات (QNX) والبساطة من أجل المتانة. كانت محاولة بناء نظام تشغيل متعدد الخوادم عالي الأداء هي مشروع IBM Sawmill Linux. [28] ومع ذلك، لم يكتمل هذا المشروع أبدًا.

لقد ثبت في الوقت نفسه أن برامج تشغيل الأجهزة على مستوى المستخدم يمكن أن تقترب من أداء برامج التشغيل الموجودة داخل النواة حتى بالنسبة للأجهزة عالية الإنتاجية وعالية المقاطعة مثل Gigabit Ethernet. [29] ويبدو أن هذا يعني ضمناً أن أنظمة الخوادم المتعددة عالية الأداء ممكنة.

حماية

لقد تمت مناقشة الفوائد الأمنية للنواة الدقيقة بشكل متكرر. [30] [31] في سياق الأمان، زعم البعض أن مبدأ الحد الأدنى للنواة الدقيقة هو نتيجة مباشرة لمبدأ الحد الأدنى من الامتيازات ، والذي بموجبه يجب أن يكون لكل التعليمات البرمجية الامتيازات اللازمة فقط لتوفير الوظائف المطلوبة. يتطلب الحد الأدنى أن تظل قاعدة الحوسبة الموثوقة (TCB) للنظام في حدها الأدنى. نظرًا لأن النواة (الكود الذي يتم تنفيذه في الوضع المميز للأجهزة) لديها وصول غير مدقق إلى أي بيانات وبالتالي يمكنها انتهاك سلامتها أو سريتها، فإن النواة تكون دائمًا جزءًا من TCB. يعد تقليلها أمرًا طبيعيًا في التصميم القائم على الأمان.

وبالتالي، تم استخدام تصميمات النواة الدقيقة للأنظمة المصممة لتطبيقات عالية الأمان، بما في ذلك KeyKOS و EROS والأنظمة العسكرية. في الواقع، تتضمن المعايير المشتركة (CC) على أعلى مستوى من الضمان ( مستوى ضمان التقييم (EAL) 7) متطلبًا صريحًا بأن يكون هدف التقييم "بسيطًا"، وهو اعتراف باستحالة إثبات الجدارة بالثقة الحقيقية لنظام معقد. مرة أخرى، فإن مصطلح "بسيط" مضلل وغير محدد جيدًا. على الأقل قدمت معايير تقييم نظام الكمبيوتر الموثوق به التابعة لوزارة الدفاع صياغة أكثر دقة إلى حد ما في فئتي B3/A1:

"يجب على TCB أن [تنفذ] آليات حماية كاملة وبسيطة من الناحية المفاهيمية مع دلالات محددة بدقة. ويجب توجيه هندسة النظام المهمة نحو تقليل تعقيد TCB، فضلاً عن استبعاد TCB من تلك الوحدات التي لا تشكل أهمية بالغة للحماية."

—  معايير تقييم نظام الكمبيوتر الموثوق به التابع لوزارة الدفاع

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

الجيل الثالث

تركزت الأعمال الأحدث على النوى الدقيقة على المواصفات الرسمية لواجهة برمجة تطبيقات النواة، والأدلة الرسمية لخصائص أمان واجهة برمجة التطبيقات وصحة التنفيذ. أول مثال على ذلك هو دليل رياضي لآليات الاحتجاز في EROS، استنادًا إلى نموذج مبسط لواجهة برمجة تطبيقات EROS. [33] في الآونة الأخيرة (في عام 2007) تم إجراء مجموعة شاملة من الأدلة التي تم فحصها آليًا لخصائص نموذج الحماية لـ seL4 ، وهي نسخة من L4. [34]

وقد أدى هذا إلى ما يشار إليه باسم الجيل الثالث من نوى المعالجات الدقيقة ، [35] والتي تتميز بواجهة برمجة تطبيقات موجهة نحو الأمان مع إمكانية الوصول إلى الموارد عن طريق القدرات ، والمحاكاة الافتراضية باعتبارها اهتمامًا من الدرجة الأولى، وأساليب جديدة لإدارة موارد النواة، [36] وهدف تصميم مناسب للتحليل الرسمي ، إلى جانب الهدف المعتاد للأداء العالي. ومن الأمثلة على ذلك Coyotos و seL4 وNova و [37] [38] و Redox وFiasco.OC. [37] [39]

في حالة seL4، تم تحقيق التحقق الرسمي الكامل للتنفيذ، [35] أي إثبات رياضي بأن تنفيذ النواة يتوافق مع مواصفاتها الرسمية. يوفر هذا ضمانًا بأن الخصائص التي تم إثباتها حول واجهة برمجة التطبيقات تنطبق بالفعل على النواة الحقيقية، وهي درجة من التأكيد تتجاوز حتى CC EAL7. تبع ذلك إثباتات لخصائص فرض الأمان لواجهة برمجة التطبيقات، وإثبات يوضح أن الكود الثنائي القابل للتنفيذ هو ترجمة صحيحة للتنفيذ C، مما يؤدي إلى إخراج المترجم من TCB. معًا، تؤسس هذه الأدلة إثباتًا شاملاً لخصائص الأمان للنواة. [40]

أمثلة

بعض الأمثلة على النوى الدقيقة هي:

نانوكيرنل

يشير مصطلح nanokernel أو picokernel تاريخيًا إلى:

  • نواة حيث يكون إجمالي كمية كود النواة، أي الكود الذي يتم تنفيذه في الوضع المميز للأجهزة، صغيرًا جدًا. تم استخدام مصطلح picokernel في بعض الأحيان للتأكيد بشكل أكبر على الحجم الصغير. تم صياغة مصطلح nanokernel بواسطة Jonathan S. Shapiro في ورقة The KeyKOS NanoKernel Architecture. كانت استجابة ساخرة لـ Mach ، التي ادعت أنها نواة صغيرة بينما اعتبرها Shapiro متجانسة وغير منظمة بشكل أساسي وأبطأ من الأنظمة التي سعت إلى استبدالها. تشير إعادة الاستخدام والاستجابة اللاحقة للمصطلح، بما في ذلك صياغة picokernel، إلى أن النقطة قد تم تفويتها إلى حد كبير. أصبح لكل من nanokernel و picokernel لاحقًا نفس المعنى المعبر عنه بمصطلح microkernel.
  • طبقة المحاكاة الافتراضية الموجودة أسفل نظام التشغيل، والتي يُشار إليها بشكل أكثر دقة باسم المشرف الافتراضي .
  • طبقة تجريد للأجهزة تشكل الجزء الأدنى مستوى من نواة النظام، وتستخدم في بعض الأحيان لتوفير وظائف في الوقت الفعلي لأنظمة التشغيل العادية، مثل Adeos .

هناك أيضًا حالة واحدة على الأقل حيث يتم استخدام مصطلح nanokernel للإشارة ليس إلى نواة صغيرة، بل إلى نواة تدعم دقة ساعة النانو ثانية . [41]

انظر أيضا

مراجع

  1. ^ Herder, Jorrit N. (23 فبراير 2005). "نحو نظام تشغيل حقيقي للنواة الدقيقة" (PDF) . minix3.org . تم الاسترجاع في 22 يونيو 2015 .
  2. ^ "اقرأ المزيد" . تم الاسترجاع في 20 ديسمبر 2016 .
  3. ^ “لكل برينش هانسن”. جمعية IEEE للكمبيوتر . تم الاسترجاع في 13 سبتمبر 2016 .
  4. ^ برينش هانسن، بير (2004). قصة مبرمج: حياة رائد الكمبيوتر . تم الاسترجاع في 13 سبتمبر 2016 .
  5. ^ Brinch Hansen, Per (April 1969). RC 4000 Software: Multiprogramming System (PDF) (تقرير فني). Regnecentralen . تم الاسترجاع في 13 سبتمبر 2016 .
  6. ^ برينش هانسن، بير (1970). "نواة نظام تشغيل متعدد البرمجة" (PDF) . اتصالات جمعية الحوسبة الآلية . 13 (4): 238-250. CiteSeerX 10.1.1.105.4204 . doi :10.1145/362258.362278. S2CID  9414037. 
  7. ^ . Wulf, William; Cohen, Ellis; Corwin, William; Jones, Anita; Levin, Roy; Pierson, C.; Pollack, Fred (June 1974). "HYDRA: The Kernel of a Multiprocessor Operating System". Communications of the ACM . 17 (6): 337–345. doi : 10.1145/355616.364017 . S2CID  8011765.
  8. ^ راشد، ريتشارد؛ روبرتسون، جورج (ديسمبر 1981). "Accent: A communication oriented network Operating system kernel". SOSP '81 Proceedings of the eight ACM symposium on Operating Systems Principles . Pacific Grove, California, USA. pp. 64–75. doi :10.1145/800216.806593.
  9. ^ Sassenrath, Carl (1986). دليل مرجعي لنواة ROM Amiga . Exec.{{cite book}}:CS1 maint: موقع الناشر المفقود ( الرابط )
  10. ^ "CMU CS Project Mach Home Page". www.cs.cmu.edu . جامعة كارنيجي ميلون . تم الاسترجاع في 8 أغسطس 2024 .
  11. ^ Jim Magee. WWDC 2000 Session 106 - Mac OS X: Kernel. 14 minutes in. مؤرشف من الأصل في 11 ديسمبر 2021.
  12. ^ "نقل تطبيقات UNIX/Linux إلى Mac OS X". Apple . تم الاسترجاع في 26 أبريل 2011 .
  13. ^ abc Liedtke, Jochen (سبتمبر 1996). "نحو نوى دقيقة حقيقية". اتصالات ACM . 39 (9): 70–77. doi : 10.1145/234215.234473 . S2CID  2867357.
  14. ^ Heiser, Gernot ; Uhlig, Volkmar; LeVasseur, Joshua (January 2006). "هل تم تصميم نوى أجهزة مراقبة الآلات الافتراضية بالشكل الصحيح؟". مراجعة أنظمة التشغيل ACM SIGOPS . 40 (1). ACM: 95–99. doi :10.1145/1113361.1113363. S2CID  7414062. مؤرشف من الأصل في 13 يناير 2014. تم الاسترجاع في 13 يناير 2014 .
  15. ^ Liedtke, Jochen (ديسمبر 1993). تحسين IPC من خلال تصميم النواة . ندوة ACM الرابعة عشرة حول مبادئ نظام التشغيل. أشفيل، كارولاينا الشمالية، الولايات المتحدة الأمريكية. ص 175-188. CiteSeerX 10.1.1.40.1293 . 
  16. ^ ab Chen, J. Bradley; Bershad, Brian N. (December 1993). "The Impact of Operating System Structure on Memory System Performance" (PDF) . SOSP '93 Proceedings of the fourteenth ACM symposium on Operating Systems Principles . Asheville, NC, USA. pp. 120–133. doi :10.1145/168619.168629.
  17. ^ abc Liedtke, Jochen (ديسمبر 1995). "On µ-Kernel Construction". SOSP '95 Proceedings of the fifteenth ACM symposium on Operating systems principles . Copper Mountain Resort, CO, USA. pp. 237–250. doi : 10.1145/224056.224075 .
  18. ^ Elphinstone, Kevin; Heiser, Gernot (نوفمبر 2013). "من L3 إلى seL4: ماذا تعلمنا في 20 عامًا من نوى L4 الصغيرة؟". SOSP '13 وقائع ندوة ACM الرابعة والعشرين حول مبادئ أنظمة التشغيل . فارمنجتون، بنسلفانيا، الولايات المتحدة الأمريكية. ص 133-150. doi : 10.1145/2517349.2522720 .
  19. ^ "تمرير الرسائل المتزامنة" . تم الاسترجاع في 3 سبتمبر 2024 .
  20. ^ "مجموعة أدوات QNX ذات التوافر العالي" (PDF) . مؤرشف من الأصل (PDF) في 24 أغسطس 2005.
  21. ^ وونغ، ويليام (27 أبريل 2007). "I/O, I/O, It's Off to Virtual Work We Go". التصميم الإلكتروني . تم الاسترجاع في 8 يونيو 2009 .
  22. ^ ألكسندر، مايكل ت. (1971). "تنظيم وخصائص نظام محطة ميشيغان". وقائع مؤتمر الكمبيوتر المشترك الخريفي الذي عقد في الفترة من 16 إلى 18 نوفمبر 1971. المجلد 40. ص 589-591. doi : 10.1145/1478873.1478951 . S2CID  14614148.
  23. ^ ليونز، جون (1 أغسطس 1977). تعليق ليونز على الإصدار السادس من يونكس، مع الكود المصدري . اتصالات نظير إلى نظير. رقم ISBN 978-1-57398-013-5.
  24. ^ ليدتكي، يوخن ؛ إلفينستون، كيفن؛ شونبيرج، سيباستيان. هارتيج، هيرمان. الأماكن القريبة : إسلام، نعيم؛ جايجر ، ترينت (مايو 1997). تم تحقيق أداء IPC (لا يزال الأساس للتوسعة) . ورشة العمل السادسة حول المواضيع الساخنة في أنظمة التشغيل. كيب كود، ماساتشوستس، الولايات المتحدة الأمريكية: IEEE. ص 28-31. دوى :10.1109/HOTOS.1997.595177.
  25. ^ جراي، تشارلز؛ تشابمان، ماثيو؛ شوب، بيتر؛ موسبرجر-تانج، ديفيد؛ هيزر، جيرنوت (أبريل 2005). إيتانيوم - حكاية منفذ النظام. المؤتمر الفني السنوي لـ USENIX. أناهايم، كاليفورنيا، الولايات المتحدة الأمريكية. ص 264-278.
  26. ^ فان شايك، كارل؛ هيزر، جيرنوت (يناير 2007). نوى دقيقة عالية الأداء والمحاكاة الافتراضية على معماريات ARM والمجزأة. ورشة العمل الدولية الأولى حول نوى دقيقة للأنظمة المضمنة. سيدني، أستراليا: NICTA. ص. 11-21. مؤرشف من الأصل في 26 أبريل 2007. تم الاسترجاع في 1 أبريل 2007 .
  27. ^ هارتيج، هيرمان؛ هوهموث، مايكل؛ ليدتك، يوشين ؛ شونبيرج، سيباستيان (أكتوبر 1997). "أداء الأنظمة القائمة على نواة μ". وقائع ندوة ACM السادسة عشرة حول مبادئ أنظمة التشغيل - SOSP '97 . المجلد 31. ص 66-77. doi :10.1145/268998.266660. ISBN 0-89791-916-5. S2CID  1706253.
  28. ^ جيفلوت ، آلان. جايجر، ترينت؛ بارك، يونهو؛ الأماكن القريبة : إلفينستون، كيفن ج. أوليج، فولكمار؛ تيدزويل، جوناثان E.؛ ديلر، لوك. وآخرون. (2000). نهج المنشرة multiserver . ورشة عمل ACM SIGOPS الأوروبية التاسعة. كولدينج، الدنمارك. ص 109 – 114. سيتيسيركس 10.1.1.25.8376 .  
  29. ^ ليزلي، بن؛ شوب، بيتر؛ فيتزروي ديل، نيكولاس؛ جوتز، ستيفان؛ جراي، تشارلز؛ ماكفيرسون، لوك؛ بوتس، دانيال؛ شين، يويتينج؛ إلفينستون، كيفن؛ هيزر، جيرنوت (سبتمبر 2005). "برامج تشغيل الأجهزة على مستوى المستخدم: الأداء المحقق". مجلة علوم الكمبيوتر والتكنولوجيا . 20 (5): 654-664. doi :10.1007/s11390-005-0654-4. S2CID  1121537.
  30. ^ تانينباوم، أندرو س. "مناظرة تانينباوم-تورفالد، الجزء الثاني".
  31. ^ تانينباوم، أ.، وهيردر، ج.، وبوس، هـ. (مايو 2006).
  32. ^ Biggs, Simon; Lee, Damon; Heiser, Gernot (2018). "The Jury Is In: Monolithic OS Design Is Flawed: Microkernel-based Designs Improve Security". وقائع ورشة العمل التاسعة لمنطقة آسيا والمحيط الهادئ حول الأنظمة . جزيرة جيجو، جمهورية كوريا: رابطة آلات الحوسبة. ص. 1-7. doi :10.1145/3265723.3265733.
  33. ^ شابيرو، جوناثان س.؛ ويبر، صموئيل. التحقق من آلية احتجاز EROS. مؤتمر معهد مهندسي الكهرباء والإلكترونيات حول الأمن والخصوصية. مؤرشف من الأصل في 3 مارس 2016.
  34. ^ Elkaduwe, Dhammika; Klein, Gerwin; Elphinstone, Kevin (2007). Verified Protection Model of the seL4 Microkernel. تم تقديمه للنشر. مؤرشف من الأصل في 29 نوفمبر 2011. تم الاسترجاع في 10 أكتوبر 2007 .
  35. ^ ab Klein, Gerwin; Elphinstone, Kevin; Heiser, Gernot; Andronick, June; Cock, David; Derrin, Philip; Elkaduwe, Dhammika; Engelhardt, Kai; Kolanski, Rafal; Norrish, Michael; Sewell, Thomas; Tuch, Harvey; Winwood, Simon (أكتوبر 2009). seL4: التحقق الرسمي من نواة نظام التشغيل (ملف PDF) . ندوة ACM الثانية والعشرون حول مبادئ نظام التشغيل. بيج سكاي، مونتانا، الولايات المتحدة الأمريكية.
  36. ^ Elkaduwe, Dhammika; Derrin, Philip; Elphinstone, Kevin (April 2008). Kernel design for isolation and insurance of physical memory. 1st Workshop on Isolation and Integration in Embedded Systems. Glasgow, UK. doi :10.1145/1435458. مؤرشف من الأصل في 24 أبريل 2010. تم الاسترجاع في 17 أغسطس 2009 .
  37. ^ "TUD Home: Operating Systems: Research: Microkernel & Hypervisor". كلية علوم الكمبيوتر . جامعة دريسدن التقنية. 12 أغسطس 2010. مؤرشف من الأصل في 6 أبريل 2012. تم الاسترجاع في 5 نوفمبر 2011 .
  38. ^ Steinberg, Udo; Kauer, Bernhard (April 2010). NOVA: A Microhypervisor-Based Secure Virtualization Architecture . Eurosys 2010. Paris, France. pp. 209–222. doi :10.1145/1755913.1755935.
  39. ^ Lackorzynski, Adam; Warg, Alexander (مارس 2009). ترويض الأنظمة الفرعية – القدرات كأداة للتحكم الشامل في الوصول إلى الموارد في المستوى الرابع. IIES'09: ورشة العمل الثانية حول العزل والتكامل في الأنظمة المضمنة. نورمبرج ، ألمانيا. CiteSeerX 10.1.1.629.9845 . 
  40. ^ كلاين، جيرفين؛ أندرونيك، يونيو؛ إلفينستون، كيفن؛ موراي، توبي؛ سيويل، توماس؛ كولانسكي، رافال؛ هيزر، جيرنوت (فبراير 2014). "التحقق الرسمي الشامل لنواة نظام التشغيل الدقيقة". معاملات ACM لأنظمة الكمبيوتر . 32 (1): 2:1–2:70. doi :10.1145/2560537. S2CID  4474342.
  41. ^ David L. Mills and Poul-Henning Kamp (28 November 2000). "The Nanokernel" (PDF) . تم الاسترجاع في 28 أغسطس 2017 .

قراءة إضافية

  • المقالات العلمية حول النوى الدقيقة (على CiteSeerX )، بما في ذلك:
    • دان هيلدبراند (1992). "نظرة عامة على بنية QNX". وقائع ورشة العمل حول النواة الدقيقة وبنى النواة الأخرى . ص 113-126. CiteSeerX  10.1.1.459.4481 . ISBN 1-880446-42-1.- المرجع الأساسي لـ QNX.
    • تانينباوم، أ.، وهيردر، ج.، وبوس، هـ. (مايو 2006). "هل يمكننا جعل أنظمة التشغيل موثوقة وآمنة؟". الكمبيوتر . 39 (5): 44-51. doi :10.1109/MC.2006.156. S2CID  99779. مؤرشف من الأصل في 21 يونيو 2017. تم الاسترجاع في 3 أبريل 2020 .{{cite journal}}:CS1 maint: أسماء متعددة: قائمة المؤلفين ( الرابط )-المرجع الأساسي الموثوق.
    • بلاك، دي إل، جولوب، دي بي، جولين، دي بي، رشيد، آر إف، درافيس، آر بي، دين، آر دبليو، فورين، إيه، باريرا، جيه، توكودا، إتش، مالان، جي، وبوهمان، دي (مارس 1992). "هندسة نظام التشغيل الميكروكيرنل وماك". مجلة معالجة المعلومات . 14 (4).{{cite journal}}:CS1 maint: أسماء متعددة: قائمة المؤلفين ( الرابط )- المرجع الأساسي لـ Mach.
  • * فارهول، بيتر د. (يناير 1994). "النوى الصغيرة تحقق نجاحًا كبيرًا". بايت . مؤرشف من الأصل في 7 مارس 2006. تم الاسترجاع في 20 سبتمبر 2017 .تقييم الحالة الحالية والمستقبلية لأنظمة التشغيل القائمة على النواة الدقيقة اعتبارًا من يناير 1994
  • صفحة MicroKernel من مستودع Portland Pattern
  • مناظرة تانينباوم -تورفالدز
    • مناظرة تانينباوم-تورفالد، 29 يناير 1992
    • تانيباوم، أ. س. "هل يمكننا أن نجعل أنظمة التشغيل موثوقة وآمنة؟".
    • تورفالدس، ل. لينوس تورفالدس يتحدث عن النوى الدقيقة مرة أخرى، 2006.05.09
    • شابيرو، ج. "فضح أحدث أفكار لينوس".
    • تانينباوم، أ. س. "مناظرة تانينباوم-تورفالد: الجزء الثاني".
تم الاسترجاع من "https://en.wikipedia.org/w/index.php?title=Microkernel&oldid=1243896977"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate