الصفحة الرئيسية / مشاكل/ توحيد Unix لأنظمة التشغيل و posix. معايير نظام التشغيل في الوقت الحقيقي

توحيد Unix لأنظمة التشغيل و posix. معايير نظام التشغيل في الوقت الحقيقي

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

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

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

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

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

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

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

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

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

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

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

كما يوحي الاسم ، POSIX (Portable نظام التشغيلالواجهة) هي معيار للواجهة (الواجهة) بين نظام التشغيل وبرنامج التطبيق. لقد ولت الأيام التي كتب فيها المبرمجون برامج لآلة "عارية" (تنفيذ الحزم الخاصة بهم من برامج الإدخال / الإخراج ، والوظائف المثلثية ، وما إلى ذلك). يؤكد نص 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 (جاد) هو لقب أحد الشخصيات ، ويمكن ترجمة الاسم بشكل مختلف: "ما مدى أهمية أن تكون إرنست." هناك لقب روسي 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	- وسائل تدمير تدفقات التحكم

المعايير

سيرجي زولوتاريف

الغرض من هذه المقالة هو محاولة لإضفاء بعض الوضوح على تاريخ تطوير معيار 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 ، الاتحاد الدولي للاتصالات (الاتحاد الدولي للاتصالات) ، ETSI (المعهد الأوروبي لمعايير الاتصالات السلكية واللاسلكية) ، CENELEC (اللجنة الأوروبية لوضع المعايير الكهروتقنية) وعلى المستوى الوطني البرامج ، على سبيل المثال ، في برنامج مثل هذه المنظمة مثل ANSI.

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

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

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

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

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

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

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

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

AustinCommonStandardsRevisionGroup (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) معمل تكنولوجيا المعلومات (معمل تكنولوجيا المعلومات - اي تي ال)، إحدى نتائجها معايير معالجة المعلومات الفيدرالية (FIPS ، www.opengroup.org/testing/fips/general_info.html). اقترحت NIST / ITL في عام 1991 مجموعة أولية من الاختبارات لشهادة POSIX بموجب FIPS PUB 151-1 1990.

ما هو بوسيكس؟

رسميا المصطلح بوسيكس اقترحه ريتشارد ستولمان كاختصار لـ صأورتابلي اتجول سواجهة 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 (تعريف نظام التشغيل) واجهات نظام التشغيل الأساسية والتحكم في الوظائف والإشارات والوظائف نظام الملفاتوالعمل مع الأجهزة ومجموعات المستخدمين وخطوط الأنابيب والمخازن المؤقتة 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 (tm) 2001. تمتلك Open Group الآن العديد من مجموعات الاختبار التي تغطي IEEE Std 1003.1-1996 ، IEEE الأمراض المنقولة جنسياً 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 المدرجة. المصطلح الثالث يعني ذلك البرمجياتتم الاجتياز بنجاح نظام مثبتالاختبارات إما بمساعدة مختبر معتمد ، أو داخل المجموعة المفتوحة وهناك دليل موثق على ذلك (ما يسمى بيان المطابقة). علاوة على ذلك في نص المقال ، سيتم الاستشهاد بأصول المصطلحات في كل مكان من أجل إزالة الغموض.

OS RV معتمد

إذا كنت تلتزم بالقواعد الصارمة التي تتطلب نشر البيانات الخاصة بـ RT OS المعتمد في السجل الرسمي ويتم إجراء الاختبار على المستوى المطابقة، ثم في الوقت الحالي لا يوجد سوى نظامي تشغيل 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 للمنصة انتلداتافوكوس إنكوربوريتد. تم إجراء الاختبار في 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. Gallmeister B. O.البرمجة للعالم الحقيقي ، POSIX.4 سيباستوبول ، كاليفورنيا: O'Reilly & Associates ، 1995.

5. المعهد الوطني للمعايير والتكنولوجيا ، PCTS: 151-2 ، POSIX Test Suite.

6. POSIX: معتمد من قبل IEEE و The Open Group. نهج معتمد. المجموعة المفتوحة ، 21 أكتوبر 2003 ، المراجعة 1.1.

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

سننظر في أحدث إصدار من معيار POSIX المتاح ، إصدار 2003 ، والذي يمكن تسميته "المعيار الثلاثي" ، أي معيار IEEE Std 1003.1 ، المعيار التقني Open Group و (انظر [6]) ، وهو الأكثر أهمية بالنسبة لنا ، المعيار الدولي ISO / IEC 9945 (انظر [1] ، [2] ، [3] ، [4]).

تاريخ إنشاء هذا الإصدار على النحو التالي. في أوائل عام 1998 ، ممثلون من ثلاث منظمات - لجنة معايير تطبيقات الهاتف المحمول التابعة لمعهد المهندسين الكهربائيين والإلكترونيين ، والفريق المفتوح ومجموعة العمل 15 التابعة للجنة الفرعية 22 التابعة للجنة الفنية المشتركة 1 (JTC1 / SC22 / WG15) التابعة للمنظمة الدولية للتوحيد القياسي - بدأت المشاورات حول الدمج وتطوير المعايير التي يشرفون عليها للواجهات مع خدمات النظام: IEEE Std 1003.1 ، IEEE Std 1003.2 ، المواصفات الأساسية من Open Group ، ISO / IEC 9945-1 ، ISO / IEC 9945-2 . في سبتمبر من نفس العام في أوستن ، تكساس ، في مكتب IBM ، تم عقد اجتماع تنظيمي للمجموعة التي تم تشكيلها لتحقيق هذا الهدف (انظر http://www.opengroup.org/austin).

كانت الوثيقة التأسيسية للمعيار المنقح ، والتي تم تقديم المسودة الأولى لها في يوليو 1999 ، هي المواصفات الأساسية من Open Group حيث تضمنت أحكام معايير IEEE و ISO / IEC. في عام 2001 ، عند الانتهاء من الأعمال التحضيرية ، احتوى المعيار على الأجزاء الأربعة التالية:

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

علاوة على ذلك ، في ISO و IEEE و Open Group بسرعة أكبر أو أقل (في 2001-2002) ، تم تمرير الموافقة الرسمية على معيار POSIX الجديد. في غضون ذلك ، تراكمت تصحيحات طفيفة نسبيًا ، تم أخذها في الاعتبار في طبعة 2003.

مع تطور المعيار ، توسع تفسير مصطلح "POSIX" أيضًا. أشارت في الأصل إلى وثيقة IEEE Std 1003.1-1988 التي تصف واجهة برمجة تطبيقنظام تشغيل من فئة يونكس. بعد توحيد الواجهة على مستوى لغة الأوامر والأداة المساعدة ، من الأصح فهم كلمة "POSIX" على أنها المعيار ككل ، مع الإشارة إلى الجزأين 2 و 3 أعلاه من خلال POSIX .1 و POSIX.2 وفقًا لـ ترقيم مستندات IEEE و ISO / IEC.

الأفكار الأساسية لمعيار POSIX

يصف معيار POSIX العديد من خدمات النظام الأساسية المطلوبة لتشغيل التطبيقات. يتم الوصول إليها من خلال الواجهة المحددة للغة C ولغة الأوامر والأدوات المساعدة العامة.

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

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

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

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

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

ما هو بوسيكس؟

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

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

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

ظهر معيار POSIX كمسودة بواسطة Richard Stallman في عام 1985 وتم إضفاء الطابع الرسمي عليه لاحقًا باسم IEEE Std 1003.-1998. كما يوحي الاسم ، كان عام 1998 عام النشر الرسمي. منذ ذلك الحين ، تم إصدار عدد كبير من الإضافات والإضافات إلى POSIX ، والتي تتحول تدريجياً إلى مجموعة كاملة من المعايير ، والمعروفة رسميًا باسم IEEE 1003 ، والمعترف بها على أنها دولية ، مع التسمية SO / IEC 9945 ، والتي تسمى ببساطة معيار عائلة POSIX .

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

نأمل أن نلقي بعض الضوء على ما هو POSIX. هل لديك معلومات مثيرة للاهتمام حول الموضوع؟ يرجى مشاركتها في التعليقات.

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

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

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

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

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

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

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

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

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

تشارك العديد من المنظمات الأخرى في تطوير واعتماد معايير 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/press/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

تم نشر الإصدار الأول من مواصفات 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.

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

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

في عام 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".

في عام 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 (الهيكل والمرافق - الأجزاء المطلوبة فقط).

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 رسميًا. والثاني يعني أن المنظمة - الشركة المصنعة لمنتج البرنامج تعلن بشكل مستقل أن هذا المنتج (كليًا أو جزئيًا) يتوافق مع معايير 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).

المؤلفات

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

توحيد Unix لأنظمة التشغيل و posix. معايير نظام التشغيل في الوقت الحقيقي

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

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

حول دلالات

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

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

استنتاج

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

المؤلفات

الأفكار الأساسية لمعيار POSIX

ما هو بوسيكس؟

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

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

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

ما هو بوسيكس؟

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

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

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

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

OS RV معتمد

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

استعادة كلمة السر