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

تتناول الدورة أحدث نسخة منها في إصدار 2003 ، والتي يمكن تسميتها "المعيار الثلاثي" ، وهي: معيار IEEE Std 1003.1 ، والمعيار التقني لمجموعة Open Group ، والأهم بالنسبة لنا ، ISO / IEC 9945 الدولي المعيار.من هذا المقرر الدراسي يدور حول فهم تقنيات وطرق استخدام المرافق والوظائف الموحدة. لم يكن الهدف إعادة سرد المعيار ، وإبراز جميع التفاصيل الدقيقة لتطبيق نظام التشغيل ، وجميع رموز الأخطاء المحتملة ، وما إلى ذلك. الشيء الرئيسي ، في رأينا ، هو الشعور بروح المعيار ، وتعلم كيفية استخدام الاحتمالات المتأصلة فيه بطريقة متنقلة. بافتراض أن القارئ يجيد لغة C ، فإننا لم نأخذ في الاعتبار وظائف مكتبة الكتب المدرسية أو النحو. بالنسبة للغة الأوامر القياسية ومترجمها ، تم توضيح هذا الموضوع ببعض التفاصيل ، على الرغم من أن العديد من المبرمجين الممارسين يفضلون استخدام مترجمين آخرين. يتم إعطاء مكانة مهمة - من حيث الحجم والدور - لأمثلة من البرامج. لم يتم ذكر العديد من أحكام المعيار (المتعلقة ، على سبيل المثال ، بمعالجة حالات الخطأ) في النص الرئيسي ، ولكن في الأمثلة المقابلة. وتم تجميع هذه الأخيرة وتنفيذها ، كلما أمكن ذلك ، على العديد من الأنظمة الأساسية للأجهزة والبرامج ، إلى واحدة درجة أو أخرى تدعي الامتثال لمعيار POSIX. ومع ذلك ، من الممكن بالتأكيد أن تكون هناك أخطاء. سنكون ممتنين لجميع التعليقات والاقتراحات المتعلقة بكل من الدورة ككل والأمثلة الفردية للبرامج.

تاريخ الإنشاء والوضع الحالي لمعيار POSIX.

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

صفحة عنوان الكتاب.
انتاج.
محاضرة 1. المفاهيم والأفكار الأساسية لمعيار POSIX.
المحاضرة 2. لغة الصدف.
المحاضرة 3. المرافق والوظائف التي تخدم مفهوم "المستخدم".
المحاضرة 4. تنظيم نظام الملفات.
المحاضرة 5. إدخال / إخراج الملف.
المحاضرة 6. أدوات لمعالجة البيانات المنظمة.
المحاضرة 7. العمليات.
المحاضرة 8. وسائل الاتصال بين العمليات.
المحاضرة 9. واجهة طرفية مشتركة.
محاضرة 10. استجواب خصائص العائل واستخدامها في التطبيقات.
المحاضرة 11. مرافق الشبكة.
المحاضرة 12. الوقت والعمل معه.
المحاضرة 13. البيئة اللغوية والثقافية.
المحاضرة 14. خاتمة.
فهرس.

تنزيل مجاني الكتاب الاليكترونيبتنسيق مناسب ، شاهد واقرأ:
قم بتنزيل كتاب البرمجة في معيار POSIX ، الجزء الأول ، Galatenko V.A. ، 2016 - fileskachat.com ، تنزيل سريع ومجاني.

POSIX و RV OS: محاولة منهجية

سيرجي زولوتاريف ، نيكولاي جوربونوف

الغرض من هذه المقالة هو محاولة لإضفاء بعض الوضوح على تاريخ تطوير معيار POSIX كما هو مطبق على أنظمة التشغيل في الوقت الفعلي (RT OS).

كمقدمة: لماذا هناك حاجة إلى توحيد واجهة البرمجة؟

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

• إعادة استخدام الكود من المشاريع السابقة والموازية ؛
• رمز النقل من أنظمة التشغيل الأخرى ؛
• جذب المطورين من مشاريع أخرى (بما في ذلك استخدام أنظمة تشغيل أخرى).

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

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

من هو في تطوير POSIX

ولن نبدأ بمعيار POSIX نفسه ، ولكن بترتيب دور المنظمات المشاركة في العمل عليه.

أول مشارك هو IEEE(معهد مهندسي الكهرباء والإلكترونيات ، معهد مهندسي الكهرباء والإلكترونيات) ، وهي جمعية عامة غير هادفة للربح من المهنيين. يعود تاريخ IEEE إلى عام 1884 (رسميًا - من عام 1963) ، ويوحد 380.000 عضوًا فرديًا من 150 دولة ، وينشر جزءًا ثالثًا من الأدبيات الفنية المتعلقة باستخدام أجهزة الكمبيوتر والتحكم والتكنولوجيا الكهربائية والمعلوماتية ، بالإضافة إلى أكثر من 100 مجلة. تحظى بشعبية بين المهنيين ؛ بالإضافة إلى ذلك ، تعقد الجمعية أكثر من 300 مؤتمر رئيسي في السنة. شارك IEEE في تطوير أكثر من 900 معيار حالي (www.ieee.ru/ieee.htm). يشارك هذا المعهد اليوم في إعداد المعايير وتنسيقها والموافقة عليها ونشرها ، ولكن نظرًا لوضعها الرسمي ، لا تتمتع بسلطة اعتماد مثل هذه الوثائق كمعايير دولية أو وطنية. لذلك ، يجب أن يُفهم مصطلح "قياسي" في فهم IEEE على أنه "مواصفات" ، وهو أكثر اتساقًا مع حالة المستندات التي تقبلها الجمعية. وفقًا لـ IEEE ، تشارك في برامج عدد من المنظمات الدولية والإقليمية - IEC و ISO و ITU (الاتحاد الدولي للاتصالات) و ETSI (المعهد الأوروبي لمعايير الاتصالات السلكية واللاسلكية) و CENELEC (اللجنة الأوروبية لوضع المعايير الكهروتقنية) وفي برامج وطنية البرامج ، على سبيل المثال ، في برنامج مثل هذه المنظمة مثل ANSI.

يتضمن IEEE PASC (لجنة معايير التطبيقات المحمولة) ، وهي لجنة جمعية تعمل على تطوير عائلة معايير POSIX (www.pasc.org/). كانت PASC تُعرف سابقًا باسم اللجنة الفنية لأنظمة التشغيل.

المشارك الثاني في العمل - ANSI(المعهد الوطني الأمريكي للمعايير ، المعهد الوطني الأمريكي للمعايير) هي منظمة خاصة غير ربحية تدير وتنسق أنشطة التقييس في الولايات المتحدة. توظف 75 شخصًا فقط ، لكن أعضاء ANSI يشملون أكثر من 1000 شركة ومنظمة ووكالات ومؤسسات حكومية (www.ansi.org). تمثل ANSI الولايات المتحدة في اثنتين من أهم هيئات المعايير الدولية ، ISO و IEC.

المشارك الثالث - ISO(المنظمة الدولية للمقاييس). تم إنشاؤه في عام 1946 بقرار من لجنة تنسيق المعايير والجمعية العامة للأمم المتحدة وبدأ العمل رسميًا في 23 فبراير 1947 (www.iso.org). ISO هي شبكة من معاهد المعايير الوطنية من 146 دولة (بلد واحد - عضو واحد في ISO) مع أمانة مركزية في جنيف (سويسرا). يتم تطوير معايير ISO في اللجان الفنية ، وأول منتج منها هو مشروع المعيار الدولي (DIS) ، والذي يصبح ، بعد عدة موافقات ، المسودة النهائية للمعيار الدولي (FDIS). بعد ذلك ، يتم طرح مسألة الموافقة على هذه الوثيقة للتصويت ؛ إذا نجح ، يصبح معيارًا دوليًا.

وأخيرا - اللجنة الكهروتقنية الدولية(اللجنة الكهرتقنية الدولية ، اللجنة الكهروتقنية الدولية - IEC) ، التي تأسست عام 1906. تعد IEC وتنشر المعايير الدولية لجميع التقنيات الكهربائية والإلكترونية والتقنيات ذات الصلة (www.iec.ch/). اعتبارًا من 1 نوفمبر 2004 ، كانت اللجان الوطنية المكونة من 64 دولة أعضاء فاعلين في هذه اللجنة. كما تنشر اللجنة الكهروتقنية الدولية التوصيات التي تنشر باللغتين الإنجليزية والفرنسية ولها صفة المعايير الدولية. على أساسها ، يتم تطوير المعايير الإقليمية والوطنية. اللجان الفنية (TC) هي المسؤولة عن إعداد المعايير في مختلف مجالات أنشطة IEC ، والتي تشارك فيها اللجان الوطنية المهتمة بأنشطة TC معينة.

IEC هي منظمة رئيسية في إعداد المعايير الدولية لتكنولوجيا المعلومات. في هذا المجال ، هناك لجنة فنية مشتركة لتكنولوجيا المعلومات - JTC 1 ، تم تشكيلها في عام 1987 وفقًا لاتفاقية بين IEC و ISO. لدى JTC1 17 لجنة فرعية تشرف على كل شيء من البرامج إلى لغات البرمجة ورسومات الكمبيوتر وتحرير الصور وربط المعدات وممارسات السلامة.

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

تشارك العديد من المنظمات الأخرى في تطوير واعتماد معايير POSIX.

مجموعة مفتوحةهي منظمة دولية لتوحيد البرمجيات ، والتي توحد ما يقرب من 200 مصنع ومجتمع مستخدمين يعملون في مجال تكنولوجيا المعلومات (www.opengroup.org/). تم تشكيل Open Group في عام 1995 من خلال دمج سابقيها: X / Open و Open Software Foundation (OSF). The Open Group متخصصة في تطوير منهجيات شهادات البرمجيات واختبار الامتثال. على وجه الخصوص ، توفر Open Group شهادات لمجالات مثل منصة COE و CORBA و LDAP و Linux Standard Base وإطار عمل التشغيل التفاعلي للمدارس (SIF) وبوابة S / MIME ومواصفات UNIX الفردية ومواصفات بروتوكول التطبيق اللاسلكي (WAP) ، وأخيرًا عائلة معايير POSIX (www.opengroup.org/certification/).

مجموعة مراجعة المعايير المشتركة في أوستن (CSRG)- تقنية مشتركة فريق العملتأسست في عام 2002 من قبل ISO و IEC و Open Group لإنشاء وصيانة أحدث الإصداراتالمعيار 1003.1 ، والذي سيتم تشكيله على أساس ISO / IEC 9945-1-1996 و ISO / IEC 9945-2-1993 و IEEE Std 1003.1-1996 و IEEE Std 1003.2-1992 ومواصفات UNIX الفردية (www.opengroup.org / اضغط / 14nov02.htm).

المعهد الوطني للمعايير والتكنولوجيا (NIST)- وكالة فيدرالية داخل إدارة التكنولوجيا بوزارة التجارة (www.nist.gov/public_affairs/general2.htm) ، تأسست في الولايات المتحدة عام 1901. تتمثل مهمة NIST في تطوير وتعزيز المعايير والتقنيات لتحسين جودة المنتج. يتضمن المعهد القومي للمعايير والتقنية (NIST) مختبرًا لتكنولوجيا المعلومات (ITL) ، وإحدى نتائجه هي معايير معالجة المعلومات الفيدرالية (FIPS ، www.opengroup.org/testing/fips/general_info.html). قدمت NIST / ITL مجموعة أولية من الاختبارات لشهادة POSIX بموجب FIPS PUB 151-1 1990 في عام 1991.

ما هو بوسيكس؟

رسميا المصطلح بوسيكساقترحه ريتشارد ستولمان كاختصار لـ صأورتابلي اتجول سواجهة ystem للأمم المتحدة التاسع(واجهة نظام تشغيل محمول لـ Unix). تم تطوير POSIX لأنظمة التشغيل الشبيهة بـ UNIX (يعود تاريخ أقدم إصداراتها إلى أوائل السبعينيات) بهدف توفير إمكانية نقل المصدر إلى التطبيقات.

تم نشر الوصف الأولي للواجهة في عام 1986 ، عندما تم تسميتها IEEE-IX (إصدار IEEE من UNIX). ومع ذلك ، تغير الاسم بسرعة ، وأصبح POSIX ، وتم بالفعل في المنشور التالي (مرة أخرى في عام 1986) هذا الجديد تم استخدام الإصدار لبعض الوقت ، تم فهم POSIX كمرجع (أو مرادف) لمجموعة من الوثائق ذات الصلة IEEE 1003.1-1988 وأجزاء من ISO / IEC 9945 ، وكمعيار دولي كامل ومعتمد ISO / IEC 9945.1: 1990 POSIX تم اعتماده في عام 1990. تحدد مواصفات POSIX آلية قياسية للتفاعل بين برنامج التطبيق ونظام التشغيل وتتضمن حاليًا أكثر من 30 معيارًا تحت رعاية IEEE و ISO و IEC و ANSI.

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

تاريخ تطوير معيار POSIX

تم نشر الإصدار الأول من مواصفات IEEE Std 1003.1 في عام 1988. بعد ذلك ، تم اعتماد العديد من الإصدارات من IEEE Std 1003.1 كمعايير دولية.

مراحل تطوير POSIX:

عام 1990

نُقحت الطبعة ، التي صدرت في عام 1988 ، وأصبحت أساسًا لمزيد من التنقيحات والإضافات. تم اعتماده كمعيار دولي ISO / IEC 9945-1: 1990.

عام 1993

تم نشر الطبعة 1003.1b-1993.

عام 1996

تم إجراء تغييرات على IEEE Std 1003.1b-1993 ، و IEEE Std 1003.1c-1995 ، و 1003.1i-1995 ، لكن معظم الوثيقة لم تتغير. في عام 1996 ، تمت الموافقة أيضًا على مراجعة IEEE Std 1003.1 كمعيار دولي ISO / IEC 9945-1: 1996.

عام 1998

ظهر المعيار الأول لـ "الوقت الفعلي" - IEEE Std 1003.13-1998. إنه امتداد لمعيار POSIX للتطبيقات المضمنة في الوقت الفعلي.

1999 سنة

تقرر إجراء تغييرات كبيرة على النص الرئيسي للمعيار لأول مرة في السنوات العشر الماضية ، بما في ذلك الدمج مع معيار 1003.2 (شل والمرافق) ، حيث كانت بحلول ذلك الوقت معايير منفصلة. قررت PASC الانتهاء من تغييرات النص الأساسي بعد الانتهاء من معايير IEEE 1003.1a و 1003.1d و 1003.1g و 1003.1j و 1003.1q و 1003.2b.

2004 ص.

تم نشر أحدث مراجعة لـ 1003.1 في 30 أبريل وتم إصدارها تحت رعاية مجموعة مراجعة المعايير المشتركة في أوستن. تم تعديله لإصدار 2001 من المعيار.عادةً ، تُعرف طبعة 2004 باسم IEEE Std 1003.1 ، إصدار 2004 ، المواصفات الأساسية القياسية التقنية للمجموعة المفتوحة ، الإصدار 6 وتتضمن IEEE Std 1003.1-2001 ، IEEE Std 1003.1-2001 / Cor 1-2002 و IEEE Std 1003.1-2001 / Cor 2-2004.

أهم معايير POSIX لنظام التشغيل RT

بالنسبة لأنظمة التشغيل في الوقت الفعلي ، فإن سبعة مواصفات للمعيار هي الأكثر أهمية (1003.1a ، 1003.1b ، 1003.1c ، 1003.1d ، 1003.1j ، 1003.21) ، لكن ثلاثة فقط تلقوا دعمًا واسعًا في أنظمة التشغيل التجارية:

• 1003.1a (تعريف نظام التشغيل)يحدد واجهات نظام التشغيل الرئيسية ، والتحكم في الوظائف ، والإشارات ، ووظائف نظام الملفات والعمل مع الأجهزة ، ومجموعات المستخدمين ، وخطوط الأنابيب ، ومخازن FIFO المؤقتة ؛
• 1003.1b (ملحقات الوقت الفعلي)يصف ملحقات الوقت الفعلي مثل إشارات الوقت الحقيقي ، وجدولة الأولوية ، وأجهزة ضبط الوقت ، والإدخال / الإخراج المتزامن وغير المتزامن ، والإشارات ، والذاكرة المشتركة ، والرسائل. في البداية (قبل 1993) تمت الإشارة إلى هذا المعيار باسم POSIX.4.
• 1003.1c (خيوط)يحدد وظائف دعم الخيط - التحكم في الخيط ، سمات الخيط ، كائنات المزامنة ، الإرسال. تم تعيينه في الأصل كـ POSIX.4a.

بالإضافة إلى هذه المعايير ، تعتبر المعايير التالية مهمة لنظام التشغيل RT ، والتي تم تنفيذها كجزء من العمل في مشروع Std 1003.1-2001:

• IEEE 1003.1d-1999.ملحقات إضافية في الوقت الحقيقي. تم تعيينه في الأصل كـ POSIX.4b ؛
• IEEE 1003.1j-2000.ملحقات الوقت الحقيقي المحسنة (المتقدمة) ؛
• IEEE 1003.1q-2000.اقتفاء أثر.

إجراء التصديق

لكي تكون متوافقًا مع POSIX ، يجب اعتماد نظام التشغيل مقابل مجموعة الاختبار المناسبة. منذ تقديم POSIX ، خضعت مجموعة الاختبار لتغييرات رسمية وفعلية.

في عام 1991 ، طورت NIST برنامج اختبار POSIX بموجب FIPS 151-1 (http://standards.ieee.org/regauth/posix/POSIX-A.FM5.pdf). اعتمد خيار الاختبار هذا على IEEE 1003.3 "معيار طرق الاختبار لقياس التوافق مع POSIX" المسودة 10 ، 3 مايو 1989. في عام 1993 ، أكملت NIST برنامج اختبار POSIX لـ FIPS 151-1 وبدأت برنامج FIPS 151-2 (www.itl.nist.gov/fipspubs/fip151-2.htm). قام FIPS 151-2 بتكييف "تقنية المعلومات - واجهة نظام التشغيل المحمولة (POSIX) - الجزء 1: واجهة برنامج تطبيق النظام (API) ،" وهو معيار ISO / IEC 9945-1: 1990. استندت مجموعات الاختبار لـ FIPS 151-2 إلى IEEE 2003.1-1992 "معيار طرق الاختبار لقياس المطابقة مع POSIX".

تميز NIST بين منهجيتين لإصدار الشهادات: الاعتماد الذاتي والشهادة من قبل مختبرات الاختبار المعتمدة من IEEE (مختبرات اختبار POSIX المعتمدة - APTL). في الحالة الأولى ، تجري الشركة الاختبار من تلقاء نفسها ، ولكن وفقًا لخطة معتمدة من NIST. في الحالة الثانية ، يتم إجراء الاختبار بواسطة مختبر مستقل باستخدام مجموعات اختبار آلية. في المجموع ، تم اعتماد معملين APTL: Mindcraft (www.mindcraft.com) و Perennial (www.peren.com).

في عام 1997 ، أعلن NIST / ITL عن نيته إنهاء شهادة FIPS 151-2 في نهاية هذا العام (رسميًا 31 ديسمبر 1997) ، بينما أعلنت Open Group أنها ستتولى المهمة اعتبارًا من 1 أكتوبر من ذلك العام. خدمة إصدار الشهادات لمدة عام وفقًا لـ FIPS 151-2 ، بناءً على برنامج NIST / ITL. تم تولي نفس الوظائف من قبل جمعية معايير IEEE (IEEE-SA) منذ 1 يناير 1998 ، وأيضًا استنادًا إلى FIPS 151-2.

في عام 2003 ، أعلنت كل من IEEE-SA و Open Group عن برنامج مشترك جديد للمصادقة على أحدث إصدارات POSIX بدءًا من IEEE 1003.1 ™ 2001. تمتلك المجموعة المفتوحة الآن العديد من مجموعات الاختبار التي تغطي IEEE Std 1003.1-1996 ، IEEE Std 1003.2-1992 و IEEE Std 1003.1-2003 و IEEE Std 1003.13-1998 (www.opengroup.org/testing/testsuites/posix.html). يعتبر المنتج معتمدًا من POSIX إذا اجتاز إجراءات الشهادة الكاملة ، وفقًا لنتائج الاختبار ، فإنه يفي بجميع المتطلبات ويتم إدخاله في السجل الرسمي للمنتجات المعتمدة.

تشمل مجموعات الاختبار:

• VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm) - مجموعة من اختبارات المطابقة لواجهات النظام IEEE Std 1003.1-1990 ؛
• VSPSE54 (www.opengroup.org/testing/testsuites/VSPSE54.htm) - مجموعة من اختبارات المطابقة لـ IEEE Std 1003.13-1998 الملف الشخصي PSE54 (الوقت الحقيقي متعدد الأغراض) ؛
• VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm) - مجموعة من اختبارات المطابقة لواجهات النظام IEEE Std 1003.1-2003 (الأجزاء الإلزامية فقط) ؛
• VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpcts2003.htm) عبارة عن مجموعة من اختبارات المطابقة لـ IEEE Std 1003.1-2003 (الهيكل والمرافق - الأجزاء المطلوبة فقط).

بالإضافة إلى ذلك ، قامت Open Group بتطوير معايير لمعايير POSIX Realtime وملف تعريف معايير POSIX المضمن. تتضمن حزمة اختبار POSIX Realtime (www.opengroup.org/testing/testsuites/realtime.html) الاختبارات التالية:

• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 تمديد Realtime و IEEE POSIX 1003.1،2003 Edition ؛
• IEEE Std POSIX 1003.1c-1995 امتداد الخيوط (pthreads) و IEEE POSIX 1003.1،2003 Edition ؛
• IEEE POSIX 1003.1d-1999 ملحق Realtime إضافي و IEEE POSIX 1003.1،2003 Edition ؛
• IEEE POSIX 1003.1j-2000 Advanced Realtime Extension و IEEE POSIX 1003.1،2003 Edition ؛
• IEEE POSIX 1003.1q-2000 Trace و IEEE POSIX 1003.1،2003 Edition و IEEE POSIX 1003.1،2003 Edition ؛

تتضمن مجموعة اختبار ملف تعريف معايير POSIX المضمنة (www.opengroup.org/testing/testsuites/embedded.html) الاختبارات التالية:

• IEEE POSIX 1003.1-1990 (5310 اختبارًا) ؛
• IEEE POSIX 1003.1b-1993 / 1003.1i-1995 تمديد الوقت الفعلي (1430 اختبارًا) ؛
• IEEE Std POSIX 1003.1c-1995 تمديد الخيوط (pthreads) (1232 اختبارًا) ؛
• ملف تعريف IEEE POSIX 1003.13-1998 52.

قليلا عن الارتباك في المصطلحات

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

• التوافق (حرفيا - "التوافق") ؛
• الامتثال (حرفيا - "الامتثال") ؛
• المطابقة (حرفيا - "الاتساق").

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

OS RV معتمد

إذا كنت تلتزم بالقواعد الصارمة التي تتطلب نشر البيانات الموجودة على نظام التشغيل RT المعتمد في السجل الرسمي ويتم إجراء الاختبار على مستوى المطابقة ، فلا يوجد في الوقت الحالي سوى نظامي تشغيل RT معتمدين (يتم تقديم البيانات بترتيب زمني):

LynxOS v.3(أحد منتجات Lynx Real-Time Systems ، التي تسمى الآن LynuxWorks ، Inc. ، www.lynuxworks.com) تم تصميمه لتطوير برامج للأنظمة المضمنة التي تعمل في الوقت الفعلي الصعب ، ومصنعي المعدات الأصلية ومعدات الاتصالات السلكية واللاسلكية ، ولا سيما الشركات المصنعة للأنظمة الموجودة على متن الطائرة للتطبيقات العسكرية ... يمكن تنفيذ التطوير على كل من النظام الهدف نفسه (مستضاف ذاتيًا) ، وعلى الكمبيوتر الآلي (المضيف) ، تم تصميم البرنامج النهائي للعمل على النظام الهدف (الهدف). تم اعتماد LynxOS v.3 لمطابقة POSIX على منصات Intel و PowerPC. يمكن العثور على معلومات حول هذا على موقع IEEE على الويب على http://standards.ieee.org/regauth/posix/posix2.html. LynxOS حاصل على شهادة POSIX 1003.1-1996 من Mindcraft ، مختبر اختبار POSIX المعتمد من IEEE POSIX في مجموعة اختبار المطابقة NIST FIPS 151-2. رقم وثيقة الشهادة: الملف المرجعي: IP-2LYX002 ، الملف المرجعي: IP-2LYX001.

النزاهة - الإصدار 5(منتج من Green Hills Software ، www.ghs.com) حاصل على توافق مع POSIX 1003.1-2003 ، واجهات النظام لهندسة PowerPC في يوليو 2004 (http://get.posixcertified.ieee.org/select_product. tpl). مجموعة اختبار VSX-PCTS 2003.

POSIX ونظام التشغيل QNX

QNX v.4.20 (تم تطويره بواسطة QNX Software Systems ، www.qnx.com) حاصل على توافق POSIX 1003.1-1988 المعتمد لمنصة Intel من قبل DataFocus Incorporated. تم إجراء الاختبار في 13 سبتمبر 1993 وتم إصداره في 1 نوفمبر 1993. مجموعة اختبار NIST PCTS 151-1 ، الإصدار 1.1.

يتوافق QNX Neutrino (الإصدار 6.3) مع معايير عائلة POSIX التالية (www.qnx.com/download/download/8660/portability.pdf):

• POSIX.1 (IEEE 1003.1) ؛
• POSIX.1a (IEEE 1003.1a) ؛
• POSIX.2 (IEEE 1003.2) ؛
• POSIX.4 (IEEE 1003.1b) ؛
• POSIX.4a (IEEE 1003.1c) ؛
• POSIX.1b (IEEE 1003.1d) ، IEEE 1003.1j ؛
• POSIX.12 (IEEE 1003.1g).

تخطط QNX Software Systems ، التي ابتكرت QNX Neutrino ، أيضًا لمطابقة QNX Neutrino مع بعض هذه المعايير ؛ الأعمال المخطط لها لعام 2005 (www.qnx.com/news/pr_959_1.html).

المؤلفات

1. دليل تشغيل جمعية معايير IEEE. IEEE ، أكتوبر 2004.
2. كيفن م. POSIX في الوقت الحقيقي ، برمجة الأنظمة المضمنة ، 2001.
3. معيار IEEE / ANSI 1003.1: تكنولوجيا المعلومات - (POSIX) - الجزء الأول: تطبيق النظام: واجهة البرنامج (API).
4. جالميستر ، ب. البرمجة للعالم الحقيقي ، POSIX.4سيباستوبول ، كاليفورنيا: O'Reilly & Associates ، 1995.
5. المعهد الوطني للمعايير والتكنولوجيا ، PCTS: 151-2 ، POSIX Test Suite.
6. POSIX: معتمد من IEEE و The Open Group.نهج معتمد. المجموعة المفتوحة ، 21 أكتوبر 2003 ، المراجعة 1.1.

أليكسي فيدورتشوك
عام 2005

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

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

هذا الوضع يجعل من الصعب كتابة تطبيقات عبر الأنظمة الأساسية. وبالتالي ، هناك ولا يزال يعمل بنشاط على تطوير مشروع لتوحيد التسلسل الهرمي للملفات - FHS (معيار التسلسل الهرمي لنظام الملفات).

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

يرتكز معيار FHS على مبدأين أساسيين - فصل واضح في التسلسل الهرمي للملفات من الدلائل المشتركة وغير المشتركة من ناحية ، والثابتة والمتغيرة من ناحية أخرى.

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

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

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

والسبب هو أن FHS يتجاهل معارضة أخرى ، وهو أمر مهم جدًا للمستخدم: معارضة الأجزاء القابلة للاسترداد بسهولة من نظام الملفات ، وتلك الخاصة بمكوناته التي يصعب استردادها أو التي لا يمكن استردادها على الإطلاق.

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

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

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

مجموعة دليل نظام POSIX النموذجية

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

يمكنك عرض تكوين الدليل الجذر باستخدام الأمر

-1 دولار ليرة سورية /

والتي ستظهر في أي نظام POSIX مجموعة قليلة من أدلة السيد المحترم:

Bin / boot / etc / root / sbin /

يتم فيها جمع جميع الملفات ، والتي بدونها لا يمكن للنظام أن يوجد. الدلائل الأخرى هي شيء من هذا القبيل:

الرئيسية / mnt / opt / tmp / usr / var /

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

بالإضافة إلى ذلك ، في معظم الحالات ، يوجد دليلان فرعيان آخران في جذر نظام الملفات لأنظمة التشغيل المتوافقة مع POSIX:

ديف / بروك /

هذه عادةً ما تكون نقاط التحميل لأنظمة الملفات الافتراضية - الأجهزة والعمليات ، على التوالي (على الرغم من أنه إذا لم يتم استخدام نظام ملفات الأجهزة ، فيجب أن يكون دليل / dev أحد مكونات نظام الملفات الجذر. وأخيرًا ، في أنظمة Linux ، مثل قاعدة ، جذر شجرة الملفات هو والدليل / lib لمكتبات النظام الرئيسية ، ومع udev ، يكون الدليل / sys الحتمي هو المكان الذي يتم فيه تركيب نظام الملفات الظاهري sysfs.

نظام ملفات الجذر

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

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

وفقًا لذلك ، يتم توفير بدء تشغيل الجهاز من خلال ملفات الدليل / التمهيد و / إلخ. الأول يحتوي على نواة النظام - ملف تنفيذي "الغرض الخاص" - وكل ما هو مطلوب لتحميله - على Linux ، على سبيل المثال ، خريطة النظام (/etc/System.map) ، وعلى FreeBSD - وحدات kernel القابلة للتحميل . ومع ذلك ، في بعض الأحيان توجد النواة مباشرة في جذر نظام الملفات ، ومن ثم قد يكون الدليل / boot غائبًا تمامًا ، وقد يكون دليل / modules محجوزًا لوحدات kernel النمطية.

الدليل / etc مخصص لملفات التكوين على مستوى النظام التي تحدد شروط تحميله. يعتمد محتواه كثيرًا على النظام (وفي Linux - أيضًا على مجموعة التوزيع) ، وبالتالي لن أعتبره هنا - سأضطر إلى العودة إلى هذا الموضوع أكثر من مرة.

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

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

لتشغيل برامج POSIX (بما في ذلك تلك المترجمة في الدلائل / bin و sbin) ، كقاعدة عامة ، تحتاج إلى الوصول إلى وظائف المكتبات على مستوى النظام (بشكل أساسي مكتبة glibc الرئيسية). وبالتالي فإن المكون الذي لا غنى عنه (تقريبًا) في الدليل الجذر هو الدليل الفرعي / lib ، حيث يتم تجميعها.

في نظام Linux ، يخدم الدليل / lib غرضًا مهمًا آخر - يحتوي دليله الفرعي (/ lib / modules) على وحدات kernel قابلة للتحميل (في FreeBSD ، مكانها هو / boot / kernel).

لا يكتشف FreeBSD الدليل / lib على نظام الملفات الجذر - يتم وضع المكونات المقابلة هنا في / usr / lib (انظر أدناه). يرجع هذا إلى أن FreeBSD ، تاريخيًا ، قد بنت برامج رئيسية على مستوى النظام بحيث يتم تضمين وظائف المكتبة التي تتطلبها في ملفاتها التنفيذية (تسمى الارتباط الثابت ، والتي سيتم مناقشتها في الفصل 14). في FreeBSD ، يتم ربط برامج الفرع الخامس من الدلائل / bin و / sbin ديناميكيًا ، أي في حالة عدم وجود دليل / usr (وفي Free يكون دائمًا فرعًا منفصلاً من نظام الملفات) لا تعمل. للتعويض عن ذلك ، يوجد دليل / استعادة يتجاوز المعايير ، ويحتوي على نفس البرامج ، ولكنه مرتبط بشكل ثابت (كما يوحي اسم الدليل ، الغرض الوحيد من محتوياته هو عمليات الإنقاذ).

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

فرع / usr

تاريخيًا ، كان الدليل / usr مخصصًا لبرامج وبيانات المستخدم. هذه الوظائف مقسمة الآن بين / usr / local و / home (على الرغم من أن الأخير أصبح الآن رابطًا رمزيًا لـ / usr / home افتراضيًا على FreeBSD). يعمل الدليل / usr - غير قابل للتغيير ، ولكنه مشترك - كمستودع لجزء كبير من برامج التطبيقات وكل ما يتعلق بها - التعليمات البرمجية المصدر وملفات التكوين والمكتبات المشتركة والوثائق وما شابه.

يختلف تكوين دليل / usr اختلافًا كبيرًا بين أنظمة BSD و Linux. في الأول ، يحتوي فقط على الأجزاء المتكاملة من نظام التشغيل (تلك التي يوحدها مفهوم التوزيعات في FreeBSD). التطبيقات المثبتة من المنافذ أو الحزم لها مكانها في الدليل الفرعي / usr / local ، والذي يمكن أن يمثل فرعًا منفصلاً من شجرة الملفات.

في Linux ، يعمل الدليل / usr كمستودع لجميع البرامج (ومكوناتها) المضمنة في مجموعة التوزيع. وعادة ما يكون الدليل الفرعي / usr / local مخصصًا للبرامج التي يتم تجميعها بشكل مستقل من المصدر.

على أي حال ، فإن التكوين المعتاد للدليل / usr هو كما يلي (كما ورد في الأمر ls -1):

X11R6 / bin / etc / include / lib / libexec / local / sbin / share / src /

كما ذكرنا سابقًا ، يعد الدليل الفرعي / usr / local فرعًا منفصلاً لشجرة الملفات ، وبالتالي سيتم اعتباره بشكل منفصل. الغرض من الأدلة الأخرى هو كما يلي:

• / usr / bin و / usr / sbin مخصصان للملفات القابلة للتنفيذ لبرامج المستخدم والنظام (هنا تكون الحدود بينهما أكثر تعسفًا مما كانت عليه في حالة الدليل الجذر) ، والغرض منها يتجاوز ضمان الأداء الأساسي لـ النظام؛
• / usr / etc مخصص لملفات تكوين التطبيقات الفردية ؛
• يحتوي / usr / include على ما يسمى بملفات الرأس المطلوبة للربط الملفات القابلة للتنفيذمع مكونات المكتبة ؛
• / usr / lib و / usr / libexec هي أدلة للمكتبات المشتركة التي تعتمد عليها تطبيقات المستخدم ؛
• / usr / share - مستودع الأكثر تنوعًا ، ما يسمى. مكونات مستقلة من الناحية المعمارية: هنا يمكنك الاطلاع على الوثائق بتنسيقات مختلفة ، وأمثلة لملفات التكوين ، والبيانات المستخدمة بواسطة برامج إدارة وحدة التحكم (الخطوط ، تخطيطات لوحة المفاتيح) ، ووصف المناطق الزمنية ؛
• / usr / src - دليل الكود المصدري ؛ في لينكس ، يتم وضع الكود المصدري للنواة (النواة) للنظام هنا بشكل طبيعي ، في استنساخ BSD - المجموعة الكاملة لمصادر المجمع ، والتي تسمى في FreeBSD التوزيعات ؛ كقاعدة عامة ، من غير المرغوب فيه وضع مصادر البرامج المجمعة ذاتيًا هنا ؛
• / usr / X11R6 - دليل لمكونات نظام نوافذ X - ملفات قابلة للتنفيذ (/ usr / X11R6 / bin) ، مكتبات (/ usr / X11R6 / lib) ، رؤوس (/ usr / X11R6 / include) ، وثائق (/ usr / X11R6 / رجل)؛ لا يجب وضع ملفات تطبيق X هنا (باستثناء ، ربما ، لمديري النوافذ) - مكانها في / usr ، / usr / local أو / opt ، اعتمادًا على النظام.

بالإضافة إلى ذلك ، قد يحتوي الدليل / usr على مجلدات فرعية / usr / var و / usr / tmp - عادةً ما تكون روابط رمزية إلى الفروع المقابلة للدليل الجذر. وفي بعض توزيعات Linux ، يتم وضع الوثائق الرئيسية على مستوى النظام - صفحات الدليل (في الدليل الفرعي / usr / man) - مباشرة في / usr.

أخيرًا ، في أنظمة BSD وبعض توزيعات Linux التي تعتمد على المصدر (على سبيل المثال ، Gentoo) ، يحتوي الدليل / usr على دليل فرعي لنظام إدارة الحزم - منافذ FreeBSD و OpenBSD (/ usr /orts) ونظرائهم في الأنظمة الأخرى (/ usr / portage في Gentoo). على الرغم من أنه من وجهة نظر الالتزام بنص وروح معيار FHS (لم يذكر هو نفسه كلمة عن المنافذ والأنظمة المماثلة) ، فإن المكان الأكثر منطقية لوضعها هو دليل var (انظر أدناه) - وهذا بالضبط ما يحدث في التوزيعات مثل CRUX و Archlinux.

فرع / البيرة / محلي

كما ذكرنا سابقًا ، فإن الفرع / usr / local في Linux مخصص لبرامج التجميع الذاتي من المصادر (غير المدرجة في مجموعة التوزيع هذه). وفي FreeBSD ، يعمل كمنزل لمعظم تطبيقات المستخدم - تقريبًا كل شيء خارج التوزيعات ويتم تثبيته من الحزم أو المنافذ. وفقًا لذلك ، تشبه بنية الدليل إلى حد كبير بنية الفرع / usr (مع استثناءات مفهومة):

Bin / etc / include / lib / man / sbin / share /

تتشابه محتويات الدلائل الفرعية أيضًا: ملفات البرامج القابلة للتنفيذ (/ usr / local / bin و / usr / local / sbin) ، وتكويناتها (/ usr / local / etc) ، والمكتبات التي ترتبط بها ، وملفات الرأس الخاصة بها (/ usr / local / lib و / usr / local / include ، على التوالي) ، وصفحات الدليل (/ usr / local / man) وجميع أنواع العناصر المستقلة عن الهندسة المعمارية (/ usr / local / share) ، بما في ذلك الوثائق بتنسيقات أخرى .

/ فرع Opt

يتم توفير دليل / opt بواسطة معيار FHS ، ولكنه في الواقع لا يستخدم في جميع توزيعات Linux ، وفي أنظمة BSD يكون غائبًا تمامًا. ومع ذلك ، تتم كتابة المزيد والمزيد من البرامج مع توقع التثبيت الافتراضي فيها.

تاريخيًا ، تم استخدام / opt في Linux للتطبيقات التجارية وجميع أنواع البرامج غير الحرة. في الوقت الحاضر ، الغرض منه هو استضافة أنظمة برمجية كبيرة قائمة بذاتها ، مثل مكتبة Qt و KDE بكل مكوناتها وتطبيقاتها و OpenOffice.org وما شابه ذلك. يجب أن تكون بنية الدليل / opt / pkg_name. هذا ما يبدو عليه في نظامي (Archlinux):

ls -1 / opt gnome / kde / OpenOffice.org1.1.2 / qt /

كل دليل فرعي له هيكله الداخلي الخاص:

$ ls -1 / opt / * / opt / gnome: bin / lib / man / share / / opt / kde: bin / etc / include / lib / share / /opt/OpenOffice.org1.1.2: help / LICENSE LICENSE. برنامج html / README README.html [بريد إلكتروني محمي]شارك / [بريد إلكتروني محمي] THIRDPARTYLICENSEREADME.html user / / opt / qt: bin / doc / include / lib / mkspecs / كتاب العبارات / الإضافات / القوالب / الترجمات /

يمكن بسهولة تخمين الغرض من الدلائل الفرعية الموجودة داخل / opt / pkg_name عن طريق القياس بـ / usr و / usr / local. على سبيل المثال ، / opt / kde / bin مخصصة للملفات القابلة للتنفيذ لنظام كيدي وتطبيقاته ، / opt / kde / إلخ لملفات التكوين الخاصة بها ، / opt / kde / include لملفات الرأس ، / opt / kde / lib للمكتبات ، و / opt / kde / share - للملفات المشتركة ، بما في ذلك الوثائق. في KDE ، لا توجد وثائق بتنسيق man ، إذا كانت كذلك ، فعندئذ (كما في حالة Gnome - لم أقم بتثبيتها ، وهذا ما سحبه Gimp وتطبيقات Gtk المماثلة) يمكنك رؤية / opt / pkg_name / دليل فرعي رجل.

يمكنك أن ترى أن بنية الدليل / opt تنحرف عن تقليد POSIX الراسخ تاريخيًا (والمؤسس داخليًا لدمج مكونات من نفس النوع في أدلة - ملفات قابلة للتنفيذ ، مكتبات ، إلخ. $ PATH ، والذي يوفر وصولاً سريعًا إلى الأوامر (والتي ستكون تمت مناقشته في الفصل 12) ، أو إنشاء دليل خاص / opt / bin ووضع روابط رمزية لثنائيات البرامج القابلة للتنفيذ. لذلك ، في بعض توزيعات Linux (على سبيل المثال ، في CRUX) لا يتم استخدام / opt من حيث المبدأ. ، في جميع أنظمة BSD. من الممكن تمامًا أن يكون أفضل بهذه الطريقة ...

/ فرع فار

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

يختلف الهيكل الداخلي لـ / يختلف اختلافًا كبيرًا من نظام إلى نظام ، وبالتالي لن أسهب في تفاصيل هيكله. سألاحظ فقط أن هذا الدليل هو مكان منطقي لوضع مكونات جميع أنواع أنظمة إدارة الحزم التي تشبه المنفذ ، كما هو الحال ، على سبيل المثال ، في توزيع Archlinux ، حيث المجلد الفرعي / var / abs (abs - Archlinux Building System) ) محجوز لذلك.

الدليل / mnt

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

في FreeBSD ، الدلائل الافتراضية لتركيب الأقراص المضغوطة والأقراص المرنة هي / cdrom و / floppy مباشرة في الدليل الجذر. وهو ما لا يتوافق تمامًا مع المعيار ، ولكنه منطقي بطريقته الخاصة - يتم نقل نقاط تحميل الأجهزة الموجودة (مثل قرص مضغوط) أو الموجودة حتى وقت قريب (محرك الأقراص المرنة) في أي جهاز إلى الجذر.

/ فرع الرئيسية

الدليل / home مخصص لاستضافة الدلائل الرئيسية للمستخدمين. لا يتم تنظيم محتواها بأي شكل من الأشكال ، ولكن عادةً ما يبدو مثل /home/ (username1 ،... ،username#). ومع ذلك ، في الأنظمة الكبيرة مع العديد من المستخدمين ، يمكن تجميع الدلائل الرئيسية الخاصة بهم معًا.

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

فرع / tmp

يبقى الحديث فقط عن دليل تخزين الملفات المؤقتة - / tmp. مثل / مكونات var ، يتم إنشاؤها بواسطة برامج مختلفة خلال حياتهم الطبيعية. ولكن ، على عكس / var ، من غير المتوقع أن تستمر مكونات / tmp خارج الجلسة الحالية. علاوة على ذلك ، توصي جميع أدلة إدارة النظام بانتظام (على سبيل المثال ، عند إعادة تشغيل الجهاز) أو مسح هذا الدليل بشكل دوري. وبالتالي ، مثل / tmp ، يُنصح بتحميل أنظمة الملفات في RAM - tmpfs (في Linux) أو mfs (في FreeBSD). بالإضافة إلى حقيقة أن هذا يضمن مسح محتوياته عند إعادة التشغيل ، فإنه يساهم أيضًا في الأداء ، على سبيل المثال ، تجميع البرامج ، التي لا تتم كتابة منتجاتها المؤقتة على القرص ، ولكن يتم وضعها في دليل افتراضي مثل / tmp / obj.

في العديد من الأنظمة ، سترى أدلة مثل / usr / tmp و / var / tmp. عادة ما تكون هذه روابط رمزية لـ / tmp.

استراتيجية تقسيم نظام الملفات

في ختام الحديث حول ملف التسلسل الهرمي ، يجب التأكيد على أن الدلائل المدرجة فقط في الفقرة نظام ملفات الجذر... يمكن لجميع الدلائل الأخرى - / usr و / opt و / var و / tmp و / home بالطبع تمثيل نقاط التحميل لأنظمة الملفات المستقلة على وسائط مادية منفصلة أو أقسامها.

علاوة على ذلك ، في شبكه محليهقد تكون هذه الدلائل موجودة حتى على أجهزة مختلفة. على سبيل المثال ، قد يحتوي جهاز كمبيوتر يعمل كخادم تطبيق على الدلائل / usr و / opt على الشبكة ، وآخر على خادم ملفات يحتوي على جميع الدلائل الرئيسية للمستخدم ، وما إلى ذلك.

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

من الواضح أن نظام الملفات الجذر في الدلائل / bin ، / boot ، / etc ، / root ، / sbin ، الذي يحتوي على سهولة الاسترداد من وسائط التوزيع والبيانات غير المتغيرة عمليًا ، يجب أن يقع على قسم قرص معزول. في Linux ، يجب أيضًا إضافة دليل / lib. من ناحية أخرى ، عند استخدام GRUB كمحمل إقلاع (بغض النظر عن نظام التشغيل) ، يوصى بنقل دليل / boot إلى قسم منفصل.

في المصادر القديمة حول Linux ، يمكنك أن تقرأ عن سبب آخر لتخصيص قسم لمجلد / boot ، وفي بداية القرص: بسبب استحالة تحميل النواة بـ Lilo من رقم أسطوانة أعلى من 1023. في الإصدارات الحديثة من لوادر التمهيد ، لا توجد مثل هذه القيود. ومع ذلك ، إذا كنت تقوم بإنشاء قسم لـ / boot ، فمن المنطقي جعله الأول على القرص ووضع قسم المبادلة خلفه مباشرةً: سيضيف هذا خمسة كوبيك إلى السرعة عند إجراء التبديل.

وشيء آخر من مجال التاريخ: مطلب أن يكون قسمي الجذر والتمهيد أساسيًا قد تمت إزالته أيضًا منذ فترة طويلة. وقد تناسب أنظمة الملفات هذه الأقسام المنطقية داخل قسم موسع.

من الواضح أيضًا أن الفروع القابلة للتغيير في نظام الملفات - / var و / tmp - يجب نقلها خارج قسم الجذر. علاوة على ذلك ، فإن الأخير ، كما قيل عدة مرات سابقًا ، يُنصح عمومًا بوضعه على نظام الملفات في ذاكرة الوصول العشوائي (tmpfs أو mfs). في حالة احتواء الدليل / var على أدلة فرعية لأنظمة إدارة الحزم التي تشبه المنفذ ، مثل / var / abs و / var / cache / pacman / src و / var / cache / pacman / pkg في Archlinux ، يجب عليهم أيضًا تكوين ملف خاص بهم أنظمة.

الآن الدليل / usr ، الذي يحتوي إما على مكونات النظام الأساسي (كما في BSD) أو الجزء الأكبر من تطبيقات المستخدم (كما هو الحال في معظم توزيعات Linux). يحتوي على بيانات يمكن استردادها بسهولة ، ولسبب وجيه ، يجب أن تكون غير قابلة للتغيير عمليًا ، وبالتالي ، بالطبع ، يستحق تسليط الضوء عليه في قسم مستقل. علاوة على ذلك ، يُنصح بعزل الدلائل الفرعية / usr / X11R6 و / usr / local عن تكوينها ، من ناحية أخرى ، الدلائل الفرعية لأنظمة إدارة الحزم الشبيهة بالمنافذ: / usr /orts، / usr / pkgsrc و / usr / pkg في أنظمة BSD و / usr / portages على Gentoo Linux وما إلى ذلك. علاوة على ذلك ، يجب فصل الدلائل الفرعية لوضع المصادر التي تم تنزيلها من الشبكة عند إنشاء المنافذ عن الأخيرة - / usr /orts / distfiles، / usr / pkgsrc / disfiles، / usr / portages / distfiles وما شابه ذلك.

في أنظمة BSD ، بالإضافة إلى ذلك ، من المنطقي فصل الدلائل الفرعية / usr / src و / usr / obj عن الدليل / usr ، والتي تحتوي على مصادر المكونات الأساسية (بما في ذلك النواة) ومنتجاتها الوسيطة للترجمة ، والتي هي تم إنشاؤها بواسطة Make buildworld وإجراء إجراءات buildkernel ...

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

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

ميزة إضافية هي أنه بالنسبة للفروع الفردية لشجرة الملفات ، اعتمادًا على طبيعة البيانات الموجودة عليها ، في Linux ، يمكنك اختيار نظام ملفات مثالي ماديًا. على سبيل المثال ، بالنسبة للقسم الموجود أسفل / boot ، ليس من المنطقي استخدام أي شيء آخر غير Ext2fs. يوصى عمومًا بتهيئة قسم الجذر باستخدام Ext3fs آمن ومع ذلك فهو الأكثر توافقًا. بالنسبة للمجلدات التي تحتوي على عدد كبير من الملفات الصغيرة ، مثل / var / abs في Archlinux و / usr / portages في Gentoo ، يُنصح باستخدام ReiserFS: بعد كل شيء ، فإن التعامل الماهر مع الملفات الصغيرة هو ملف التعريف الخاص بها. وفي الدليل / home ، حيث يمكن أن تظهر ملفات الوسائط المتعددة الضخمة (والتي عادة ما تكون كبيرة جدًا في حد ذاتها) ، قد يصل XFS إلى المحكمة (على الرغم من أنه ، كما تظهر القياسات ، يبدو ReiserFS لائقًا تمامًا هنا). يمكن لمثل هذه الإجراءات تحسين موثوقية تخزين البيانات وسرعة عمليات الملفات.

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

حول المعايير بشكل عام

هناك رأي بين المبرمجين الممارسين أن المعايير في البرمجة ليست ضرورية على الإطلاق ، للأسباب التالية:

(1) كانت في البداية بلا معنى ، لأن مؤلفيها لا يكتبون برامج الكمبيوتر ؛

(2) يقيدون مبادرة المبرمجين.

(3) سيوافق المبرمجون دائمًا بدون معايير.

ربما لم يكن ينبغي الالتفات إلى هذا الرأي ، إن لم يكن لسببين:

(1) يتم التعبير عنها من قبل الممارسين ، أي بالتحديد من قبل أولئك الذين "يصدرون البرمجيات" ؛

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

عادة ما ترتبط كلمة "قياسي" بشيء ما (الأبعاد القياسية ، الجهد الكهربائي القياسي ، إلخ) ، بينما برنامج الكمبيوتر هو كائن غير ملموس ("غير الملموس الجديد") ، وربما تكون المعايير في المجال غير الملموس غير مجدية حقًا؟

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

الغرض و "المهمة الفائقة" لمعيار POSIX

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

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

دعنا نوضح أنه في هذه المقالة سنتحدث فقط عن معيار واجهة برنامج التطبيق ، POSIX.1 ، الإصدار الثاني (والأخير حتى الآن) الذي تمت الموافقة عليه في 12 يوليو 1996.

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

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

حول دلالات

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

كيف تنقل المعنى في الترجمة

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

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

دلالات كلمة "قياسي"

يسبق النص الرئيسي للمعيار ديباجة تشرح معنى الكلمات معايير IEEE 2. على النحو التالي من هذه التفسيرات ، هناك ثلاثة اختلافات دلالية على الأقل من مصطلح GOST باللغة الروسية:

(1) يعتبر بديهيًا أن GOST لها قوة القانون ، حيث تتم مقاضاة انتهاكه ؛ POSIX عبارة عن مجموعة من المتطلبات ، والالتزام بها طوعي تمامًا.

(2) GOST صالح حتى يتم إلغاؤه (ربما سمع الكثيرون عبارة "لم يتم إلغاء GOST") ؛ تنص مقدمة نظام POSIX على أنه إذا لم يتم مراجعة المعيار لمدة 5 سنوات ، فهذا يعني أن المشكلات التي تم بحثها فيه من المحتمل أن تكون قد فقدت ملاءمتها ، ويمكن اعتبارها ملغاة تلقائيًا ؛

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

وبالتالي ، فإن ترجمة حتى كلمة مشهورة مثل "قياسي" بكلمة "قياسي" تتطلب تعليقات.

دلالات الكلمات "ينبغي" ، "غير محدد" ، "غير محدد" ، "محدد بالتنفيذ"

يسمى القسم 2 من المعيار المصطلحات والمتطلبات العامة. إنه يحتوي على تعريفات ليس فقط للمصطلحات الخاصة (مثل "عملية" أو "إشارة") ، ولكن أيضًا كلمات بديهية ظاهريًا مثل "ينبغي" أو "يجوز". نظرًا لأن POSIX.1 هو معيار واجهة ، فإن متطلباته تنطبق على كل من نظام التشغيل وبرنامج التطبيق. يتم التعبير عن شرط صريح بكلمة "يجب" ، على سبيل المثال: "إذا نجح الارتباط () ، يجب أن يُرجع صفرًا." في هذا المثال ، نتحدث عن أحد متطلبات نظام التشغيل: يجب تنفيذ وظيفة link () بحيث تُرجع صفرًا عند النجاح.

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

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

دعنا نعطي مثالاً: "يجب أن تعيد الدالة readdir () مؤشرًا إلى بنية مرتبطة بالعنصر التالي في الدليل. ما إذا كان يتم إرجاع عناصر الكتالوج المسماة "نقطة" و "نقطة إلى نقطة" أم لا بواسطة المعيار. " في هذا المثال ، هناك أربع نتائج محتملة ، ومتطلب التطبيق هو أنه يجب تصميمه لأي منها.

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

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

يتطلب هذا المثال من التطبيق استبدال مرجع دليل مفتوح فقط لوسيطة دالة readdir () ؛ يمكن أن يؤدي انتهاك هذا المطلب إلى عواقب وخيمة ، وتقع مسؤولية ذلك على عاتق مبرمج التطبيق.

إليك مثال آخر: "إذا نجحت ، يجب أن تُرجع الدالة read () عددًا صحيحًا يمثل عدد البايتات التي تمت قراءتها بالفعل. وإلا ، يجب على الوظيفة تعيين رمز الخطأ إلى errno والعودة -1 ، ومحتويات المخزن المؤقت المشار إليها بواسطة buf غير محددة. "

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

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

دلالات افتراضية

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

عمليات وتدفق السيطرة

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

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

يجب التأكيد على أن فكرة تعدد مؤشرات الترابط يتم تنفيذها في العديد من أنظمة التشغيل في الوقت الفعلي ، ويتم تنفيذها بطرق مختلفة بمعنى أن لكل مؤشر ترابط تحكم مجموعة مختلفة من السمات ووظائف الواجهة ؛ أحيانًا يتم استخدام مصطلح المهمة بدلاً من الخيط. لتجنب الالتباس ، يؤكد المعيار أنه يتعامل حصريًا مع سلاسل POSIX ، وأن أسماء وظائف الواجهة المقابلة مسبوقة بـ pthread_ (على سبيل المثال ، pthread_create () ، pthread_join () ، إلخ).

الامتثال للمعيار. دلالات كلمة "تطابق"

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

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

• الامتثال الصارم لمعيار POSIX.1 ؛
• الامتثال للنسخة الدولية POSIX.1 ؛
• الامتثال للنسخة الوطنية من POSIX.1 ؛
• التوافق مع ملحقات POSIX.1.

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

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

كائنات التوحيد القياسي وهيكلية

باختصار ، فإن كائنات توحيد POSIX.1 هي أسماء ودلالات. بشكل أكثر تحديدًا ، نحن نتحدث عن ما يلي.

• أسماء وظائف الواجهة. 357 وظيفة موحدة ، مع 107 وظيفة مأخوذة من مكتبات C القياسية (حسابية ، معالجة سلسلة ، إدخال / إخراج ، إلخ) ؛ تعتبر هذه الوظائف جزءًا من معيار POSIX.1 ، لكنها كذلك وصف كاملالواردة في المعيار الخاص بلغة البرمجة C.
• أسماء أنواع بيانات النظام. هذه الأسماء مُلحقة بـ _t.
• أسماء ملفات الرأس ، وكذلك الحد الأدنى من تكوين هذه الملفات.
• أسماء المتغيرات الشاملة على مستوى النظام (على سبيل المثال ، errno).
• الأسماء الرمزية لرموز الخطأ التي يمكن تعيينها أثناء تنفيذ الوظيفة. تبدأ هذه الأسماء بالحرف E (EPERM ، ENOTEMPTY ، إلخ.).
• تكوين أسماء ثابتة. هذه الأسماء مسبوقة بـ _POSIX_.
• الأسماء الرمزية لأرقام الإشارات ؛ هذه الأسماء مسبوقة بـ SIG. بالإضافة إلى 20 إشارة "تقليدية" (SIGABRT ، SIGALRM ، وما إلى ذلك) ، يتم توحيد إشارات الوقت الفعلي ، ويجب أن تشغل أرقامها نطاقًا مستمرًا معينًا من SIGRTMIN إلى SIGRTMAX ، بما في ذلك أرقام RTSIG_MAX على الأقل.
• الأسماء الرمزية المطابقة لقيم الوسائط الفردية لبعض الوظائف (على سبيل المثال ، يمكن أن تأخذ الوسيطة cmd للوظيفة fcntl () القيم F_DUPFD و F_GETFD و F_GETLK وما إلى ذلك).
• أسماء وحدات الماكرو ، الثوابت ، أعلام البت ، متغيرات البيئة.

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

يعطي الشريط الجانبي "ملخصات فقرات المعيار" فكرة عن أنواع خدمات نظام التشغيل التي يغطيها المعيار.

استنتاج

المحتوى الرئيسي لمعيار POSIX هو دلالات وظائف الواجهة. إن توحيد دلالات الكلمات ليس عملاً سهلاً في حد ذاته (يعلم الجميع مدى صعوبة التوصل إلى اتفاق حتى بالنسبة لشخصين) ، وتتفاقم الصعوبات بسبب حقيقة أن الكثير من الأشخاص يشاركون حاليًا في البرمجة. على سبيل المثال ، يتم التعبير عن نموذج التزامن بعبارات مثل "العملية" و "المهمة" و "تدفق التحكم" ، ولكن من وجهة نظر البرمجة العملية ، يتم التعبير عن "المهمة" في نظام التشغيل IBM OS / 360 والحقيقي نظام تشغيل الوقت VxWorks ليس هو نفسه. مثال آخر هو الإشارات. الإشارات هي ثنائية ، عدد صحيح ("مع عداد") وإقصاء متبادل (والذي ، بالمناسبة ، يسمي المبرمجون فيما بينهم "كائنات" ، يحاولون تلقائيًا تجنب سوء الفهم). والإشارات الصحيحة ، على سبيل المثال ، في نظام التشغيل VxWorks ، ليست مثل إشارات POSIX.

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

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

نبذة عن الكاتب

سيرجي رومانيوك - كبير الباحثين في معهد البحوث لأبحاث النظام ، ورئيس مجموعة المترجمين المعياريين POSIX. يمكن الاتصال به عبر البريد الإلكتروني على: [بريد إلكتروني محمي]

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

2 IEEE هي المنظمة التي طورت معيار POSIX.

3 هنا تعني كلمة "افتراضي" صامت ، وليس افتراضي ؛ نحن لا نتحدث عن بعض القيم الضمنية المعلنة بالفعل ، ولكن عن عدم وجود مراجع على الإطلاق.

4 سيتم نشر ترجمة روسية للمعيار في أوائل عام 2000.

المؤلفات

المعيار الدولي ISO / IEC 9945-1 (ANSI / IEEE Std 1003.1) الإصدار الثاني. 1996-07-12. تكنولوجيا المعلومات - واجهة نظام التشغيل المحمولة (POSIX) - الجزء 1: واجهة برنامج تطبيق النظام (API).

إم آي بيلياكوف ، يو آي رابوفر ، أل فريدمان. نظام تشغيل الموبايل. الدليل. موسكو ، "راديو واتصالات" ، 1991.

ISO / IEC 9899: 1990 ، لغات البرمجة - C.

القسم 1	- مقدمة
القسم 2	- المصطلحات والتعاريف
قسم 3	- وظائف لإدارة العمليات (إنشاء واستبدال صورة واستكمالها) والإشارات (إدارة الأقنعة والاستجابة للإشارات)
القسم 4	- تحديد (العمليات ، المستخدمون ، النظام ، المحطة الطرفية) ، استقصاء الوقت المستغرق في تنفيذ العملية ، استقصاء متغيرات البيئة.
القسم 5	- إدارة الملفات والدليل
القسم 6	- وظائف الإدخال والإخراج
القسم السابع	- وظائف التحكم في المحطة الطرفية
القسم 8	- وظائف مستعارة من معيار لغة سي
القسم 9	- الوصول إلى قواعد بيانات المستخدمين ومجموعات المستخدمين
القسم 10	- تنسيقات البيانات للأرشفة والتبادل (tar و cpio)
القسم 11	- مرافق التزامن: الإشارات ، كائنات المزامنة ومتغيرات الشرط
القسم 12	- وظائف إدارة الذاكرة: تثبيت مساحة عنوان العملية وإلغاء تثبيتها ، وتعيين الملفات إلى الذاكرة ، وحماية الذاكرة ، والذاكرة المشتركة
القسم 13	- الوظائف المتعلقة بجدولة العمليات والتحكم في التدفقات
القسم 14	- إدارة الساعة والمؤقت
القسم 15	- إدارة قائمة انتظار الرسائل
القسم 16	- الوظائف الأساسية المتعلقة بالتحكم في التدفقات
القسم 17	- بيانات خيوط محددة
القسم 18	- وسائل تدمير تدفقات التحكم

الموضوع: أنظمة التشغيل.
السؤال: رقم 8

—————————————————————

مبادئ بناء نظام التشغيل:

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

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

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

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

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

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

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

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

- ذاكرة افتراضية ذات حجم غير محدود عمليا وموحدة من حيث منطق العملية.

- عدد اعتباطي من المعالجات الافتراضية القادرة على العمل بالتوازي والتفاعل أثناء التشغيل.

- عدد عشوائي من الأجهزة الظاهرية الخارجية القادرة على العمل مع ذاكرة جهاز افتراضي بالتوازي أو بالتتابع ، أو بشكل غير متزامن أو متزامن فيما يتعلق بتشغيل معالج ظاهري واحد أو آخر الذي يبدأ تشغيل هذه الأجهزة.

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

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

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

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

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

من الأصعب بكثير تحقيق التوافق الثنائي بين المعالجات بناءً على بنيات مختلفة. لكي ينفذ أحد أجهزة الكمبيوتر برامج لجهاز آخر (على سبيل المثال ، من المستحسن تشغيل برنامج لجهاز كمبيوتر مثل كمبيوتر IBM الشخصي على جهاز كمبيوتر مثل Apple Macintosh) ، يجب أن يعمل هذا الكمبيوتر مع تعليمات الجهاز التي لم يفعلها في البداية تفهم. في هذه الحالة ، يجب تنفيذ معالج 680x0 (أو PowerPC) كود ثنائيمصمم لمعالج i80x86. يحتوي المعالج 80x86 على وحدة فك ترميز التعليمات والسجلات والبنية الداخلية الخاصة به. لا يفهم المعالج 680x0 ثنائي 80x86 ، لذلك يجب تحديد كل أمر وفك تشفيره لتحديد ما إذا كان

ما هو المقصود به ، ثم تنفيذ الإجراء الفرعي المكافئ المكتوب لـ 680 × 0.

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

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

9.) مبدأ التنقل:يجب أن يكون نظام التشغيل سهل الحمل نسبيًا

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

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

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

كان الهدف من إدخال معايير POSIX هو ضمان قابلية البرنامج الذي تم إنشاؤه للنقل.

10.) مبدأ أمان الحوسبة:يعد ضمان الأمن الحسابي ميزة مرغوبة لأي نظام متعدد المستخدمين. تحدد قواعد الأمان خصائص مثل حماية موارد أحد المستخدمين من الآخرين وتعيين حصص الموارد لمنع مستخدم واحد من الاستيلاء على جميع موارد النظام ، مثل الذاكرة.

يعد ضمان حماية المعلومات من الوصول غير المصرح به وظيفة إلزامية لأنظمة تشغيل الشبكة.

—————————————————————

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

يصف هذا المعيار بالتفصيل نظام الذاكرة الظاهرية VMS (نظام الذاكرة الظاهرية) وتعدد المهام MPE (تنفيذ العمليات المتعددة) و CTOS (نظام تشغيل أنتج تقنية متقاربة ...). وبالتالي ، فإن POSIX هي في الواقع مجموعة من المعايير تسمى POSIX.I –POSIX.12. وتجدر الإشارة أيضًا إلى أن POSIX.1 يفترض أن لغة C هي اللغة الرئيسية.

لغة وصف وظائف نظام API.

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

تختلف تطبيقات نظام التشغيل لـ POSIX API. إذا كانت الغالبية العظمى من أنظمة UNIX تتوافق في البداية مع مواصفات IEEE Standard 1003.1-1990 ، فإن WinAPI لا يتوافق مع POSIX. ومع ذلك ، لدعم هذا المعيار في نظام التشغيل MS Windows NT ، تم تقديم وحدة دعم POSIX API خاصة تعمل على مستوى امتياز عمليات المستخدم.

توفر هذه الوحدة تحويل وتحويل المكالمات من برنامج المستخدم إلى نواة النظام والعكس ، والعمل مع النواة من خلال Win API. يمكن للتطبيقات الأخرى التي تم إنشاؤها باستخدام WinAPI تمرير المعلومات إلى تطبيقات POSIX من خلال آليات دفق الإدخال / الإخراج القياسية (stdin ، stdout).

لا يوجد منشورات ذي علاقة ...