Інтерфейс командного рядка в posix. Основні поняття і ідеї стандарту POSIX. Що таке POSIX

Великі відмінності в специфікаціях ОСРВ і величезна кількість існуючих мікроконтролерів висувають на передній план проблему стандартизації в області систем реального часу.

Найбільш раннім і поширеним стандартом ОСРВ є стандарт POSIX (IEEE Portable Operating System Interface for Computer Environments, IEEE 1003.1). Початковий варіант стандарту POSIX з'явився в 1990 р і був призначений для UNIX-систем, перші версії яких з'явилися в 70-х роках минулого століття. Специфікації POSIX визначають стандартний механізм взаємодії прикладної програми і операційної системи і в даний час включають набір більш ніж з 30 стандартів. Для ОСРВ найбільш важливі сім з них (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), але широку підтримку в комерційних ОС отримали тільки три перших.

Незважаючи на явно застарілі положення стандарту POSIX і велику затребуваність оновлень стандартизації для ОСРВ, помітного просування в цьому напрямку не спостерігається.

Стандарт POSIX був створений як стандартний інтерфейс сервісів операційних систем. Цей стандарт дає можливість створювати стерпні додатки. Згодом цей стандарт був розширений особливостями режиму реального часу.

Специфікації POSIX задають стандартний механізм взаємодії ОС і програми. Необхідно відзначити, що стандарт POSIX тісно пов'язаний з ОС Unix, тим не менш, розробники багатьох ОСРВ намагаються витримати відповідність цьому стандарту.

Відповідність стандарту POSIX для ОС і апаратної платформи повинна бути сертифікована за допомогою прогону на них тестових наборів. Однак, якщо ОС не є Unix-подібної, витримати цю вимогу стає непростим завданням. Тестові набори існують тільки для POSIX 1003.1a. Оскільки структура POSIX є сукупністю необов'язкових можливостей, постачальники ОС можуть реалізувати тільки частина стандартного інтерфейсу, і при цьому говорити про POSIX-компліантності своєї системи.

Незважаючи на те, що стандарт POSIX виріс з Unix "а, він зачіпає основоположні абстракції операційних систем, а розширення реального часу пишуться для всіх ОСРВ.

До теперішнього часу стандарт POSIX розглядається як сімейство споріднених стандартів: IEEE Std 1003.n (де n - це номер).

Про стандарти взагалі

Серед практикуючих програмістів існує думка, що стандарти в програмуванні взагалі не потрібні, оскільки:

(1) вони спочатку безглузді, так як їх автори не пишуть комп'ютерних програм;

(2) вони сковують ініціативу програмістів;

(3) програмісти завжди домовляться і без стандартів.

Може бути, на це думка не варто було б звертати уваги, якби не дві обставини:

(1) його висловлюють практики, тобто саме ті, хто «видає програмну продукцію»;

(2) наведена вище аргументація була виявлена \u200b\u200bавтором даної статті в одній з публікацій в Internet, присвяченій стандарту на мову програмування Сі, з чого стало ясно, що така думка поширена «в міжнародному масштабі», а не тільки серед зарозумілих російських «суперпрограммістов».

Слово «стандарт» асоціюється зазвичай з чимось матеріальним (стандартні габарити, стандартне електрична напруга і т.д.), в той час як комп'ютерна програма - об'єкт нематеріальний ( «The new intangible»), і може бути, стандарти в нематеріальній сфері дійсно безглузді?

Існує, однак, спростовує приклад. Сукупність правил орфографії російської мови по суті являє собою стандарт, хоча і не затверджений органами стандартизації. Далі, крім правил (або, якщо завгодно, вимог) орфографії, існують синтаксичні правила і, найголовніше, семантика. Останнє добре ілюструє «дитячий» питання: чому кішку називають кішкою? На це питання існує точну відповідь: тому, що наші предки так домовилися; предки англійців домовилися називати цього ж звіра cat, предки німців - kitten, і т.д. І взагалі, сенс, або семантика, або правила інтерпретації будь-якого слова або поєднання слів - питання домовленості.

Призначення і «надзавдання» стандарту POSIX

Як випливає з назви, POSIX (Portable Operating System Interface) - це стандарт на пару (інтерфейс) між операційною системою і прикладної програмою. Часи, коли програмісти писали програми для «голої» машини (реалізуючи власні пакети програм введення / виведення, тригонометричних функцій і т.п.), пройшли безповоротно. У тексті POSIX неодноразово підкреслюється, що стандарт не висуває ніяких вимог до деталей реалізації операційної системи; його можна розглядати як сукупність домовленостей між прикладними програмістами і розробниками операційних систем. Таким чином (знову ж таки всупереч досить поширеній думці), POSIX представляє інтерес не тільки для розробників операційних систем, але перш за все для набагато більш численної категорії програмістів - прикладних.

Потреба в стандарті такого роду була усвідомлена ще в 1980-і роки, коли набули широкого поширення операційні системи UNIX. Виявилося, що хоча ця система і замислювалася як уніфікована, відмінності між конкретними її реалізаціями приводили до того, що прикладні програми, написані для однієї системи, далеко не завжди могли виконуватися в інший. На рішення саме цієї проблеми, відомої як проблема мобільності програмного забезпечення, Націлений POSIX. Перша редакція стандарту була випущена в 1988 році (мається переклад, см.), В якій все різноманіття питань, пов'язаних з мобільністю програм, було розбито на дві частини: (1) інтерфейс прикладних програм, (2) командний інтерпретатор і утиліти (інтерфейс користувача); ці частини отримали назву POSIX.1 і POSIX.2 соответственно1.

Уточнимо, що в даній статті мова піде тільки про стандарт на інтерфейс прикладних програм, POSIX.1, друга (і остання на сьогодні) редакція якого була затверджена 12 липня 1996 року.

В інформативній частині стандарту підкреслюється також, що POSIX є не опис інтерфейсу деякої «ідеальної» операційної системи, а результат узагальнення і систематизації досвіду, накопиченого при розробці операційних систем UNIX. Крім того, POSIX не може служити керівництвом або навчальним посібником по операційним системам, хоча в інформативній частині містяться рекомендації програмістам і фрагменти програм.

У стандарті прямо говориться про те, що неможливо створити повноцінну операційну систему, орієнтуючись виключно на описані в ньому інтерфейсні функції. (Зокрема, в POSIX.1 не відображені такі питання, як робота в мережі і відповідні інтерфейсні функції або графічний інтерфейс.) Проте, фінансові витрати, викликані немобільні програм і випливає звідси потреба в уніфікації інтерфейсу настільки великі, що більшість виробників вважає за краще мати хоч який-небудь стандарт, ніж не мати ніякого. З цієї причини на POSIX прагнуть орієнтуватися дуже багато розробників програмного забезпечення. Це дозволяє якщо не ліквідувати немобільності програм повністю, то принаймні суттєво зменшити немобільні частина програми.

Про семантику

Як вже говорилося, POSIX можна розглядати як сукупність домовленостей між розробником операційної системи і прикладних програмістом. «Домовленість» означає насамперед однаковість інтерпретації (семантики) слів і виразів. Далі наводяться приклади, що ілюструють складність завдання досягнення «домовленості».

Як передати сенс при перекладі

Перш за все, потрібно нагадати, що стандарт POSIX викладено англійською мовою, який за своєю природою провокує двозначності (наприклад, одне і те ж слово може бути іменником, прикметником і дієсловом), і «семантичні пастки» підстерігають мало не на кожній сторінці. Доброю ілюстрацією сказаного є приклад з художньої літератури. Одне з найвідоміших творів Оскара Уайльда, який блискуче користувався цією особливістю англійської мови, - The Importance of being Earnest - відомо російською під назвою «Як важливо бути серйозним». Однак англійська назва має другий сенс: Earnest (серйозний) - прізвище одного з персонажів, і назву можна було б перевести інакше: «Як важливо бути Ернстом». Є російське прізвище Срібний, і якби була прізвище Серйозний, переклад був би ідеально точним, з передачею обох сенсів.

Аналогічно іде справа з самою назвою стандарту: Portable Operating System Interface. Прикметник Portable (мобільний) відноситься і до операційної системи, і до прикладної програми, але висловити це так само коротко по-російськи не вдається, можна перевести як «Інтерфейс мобільної операційної системи» або «Інтерфейс операційної системи, що забезпечує мобільність прикладних програм». Другий варіант краще відображає наміри розробників стандарту, але при цьому втрачається перший змив (при перекладі був збережений більш звичний перший варіант).

Семантика слова «стандарт»

Основний текст стандарту передує преамбулою, в якій роз'яснюється зміст слів IEEE Standards2. Як випливає з цих роз'яснень, існує принаймні три смислових відмінності від російськомовного терміна ГОСТ:

(1) Інтуїтивно вважається, що ГОСТ має силу закону, порушення якого переслідується; POSIX - сукупність вимог, дотримання яких - справа виключно добровільна.

(2) ГОСТ діє аж до скасування (багатьом, напевно, доводилося чути вираз «ГОСТ ніхто не відміняв»); в преамбулі до POSIX йдеться, що якщо стандарт не переглядався протягом 5 років, це означає, що розглядаються в ньому питання, швидше за все, втратили актуальність, і його можна вважати скасованим автоматично;

(3) ГОСТ анонімний; у вступній частині POSIX наводиться список тих осіб, які брали участь в розробці цього стандарту, а також дається адреса, за якою можна направляти запити по інтерпретації; йдеться також, що відповідь на кожен запит піддається процедурі узгодження (іншими словами, автори стандарту домовляються між собою, перш ніж дати відповідь).

Таким чином, переклад навіть такого загальновідомого слова як Standard словом «стандарт» вимагає коментарів.

Семантика слів «повинен», «Не специфіковане», «не визначене», «визначається реалізацією»

Розділ 2 стандарти називається «Термінологія і загальні вимоги». У ньому містяться визначення не тільки спеціальних термінів (на кшталт «процес» або «семафор»), а й таких, здавалося б, самоочевидних слів, як «повинен» або «може». Оскільки POSIX.1 - стандарт на інтерфейс, то його вимоги ставляться як до операційної системи, так і до прикладної програми. Явна вимога виражається словом «повинен» (shall), наприклад: «У разі успішного завершення функція link () повинна повертати нульове значення». В даному прикладі мова йде про вимогу до операційній системі: функція link () повинна бути реалізована так, щоб при успішному завершенні повертала нульове значення.

Терміни «Не специфіковане» і «не визначено» висловлюють одну й ту ж ідею яка полягає в тому, що стандарт допускає свободу вибору, однак зміст цих термінів різний. Термін «Не специфіковане» має на увазі, що мова йде про якісь коректних (діях, програмних конструкціях і т.д.), а термін «не визначене» - про некоректні (помилкових). В інформативній частині стандарту наводиться наступне пояснення.

Термін «Не специфіковане» означає, що безліч варіантів (результатів, результатів виклику функції і т.д.) передбачається відомим, і стандарт допускає будь-який з них; в конкретної реалізації операційної системи може бути обраний будь-який, і така система вважається відповідної стандарту. Прикладна програма (строго відповідає стандарту) повинна бути написана так, щоб коректно працювала при будь-якому варіанті; по суті, цим терміном неявно виражається вимога до прикладній програмі.

Наведемо приклад: «Функція readdir () повинна повертати покажчик на структуру, яка відноситься до чергового елементу каталогу. Чи повертаються елементи каталогу з іменами «точка» і «точка - точка», стандартом не специфіковане ». У цьому прикладі можливо чотири результату, а вимога до прикладній програмі полягає в тому, що вона повинна бути розрахована на будь-який з них.

Інший приклад: «Якщо функція sigwait (), відповідно до якої очікування сигналу з зазначеним номером, викликана в декількох потоках управління, то при надходженні сигналу не більше ніж в одному з них повинен відбутися повернення з sigwait (). В якому саме потоці управління це станеться, стандартом не специфіковане. » У цьому прикладі безліч можливих результатів може виявитися більше, але всі вони також відомі, і вимога до прикладній програмі полягає в тому, що вона повинна правильно працювати при будь-якому результаті.

Термін «не визначене» має на увазі, що навіть безліч випадків не відомо, можливий будь-який результат, навіть жалюгідний (наприклад, крах системи, втрата даних і т.п.). По суті, цим терміном неявно виражається вимога до прикладної програмі використовувати відповідні дані або конструкції. Наприклад: «Якщо аргумент dirp функції readdir () не посилається на відкритий в даний момент каталог, результат не визначений».

У цьому прикладі міститься вимога до прикладній програмі підставляти в якості аргументу функції readdir () тільки посилання на відкритий каталог; порушення цієї вимоги може привести до катастрофічних наслідків, і відповідальність за це покладається на прикладного програміста.

Ось ще один приклад: «У разі успішного завершення функція read () повинна повернути ціле число, що позначає кількість фактично прочитаних байт. В іншому випадку функція повинна привласнити змінної errno код помилки і повернути -1, причому вміст буфера, на який вказує аргумент buf, не визначене. »

Використання в прикладній програмі даних з буфера в разі помилки функції read () стандарт забороняє, і наслідки порушення цієї вимоги покладає на прикладного програміста.

Сенс терміна «визначається реалізацією» відрізняється від інтуїтивного. Очевидно, що в конкретній операційній системі не може бути «неспеціфіцірованного» або «невизначеного» результату, якийсь конкретний результат буде отримано обов'язково. Термін «визначається реалізацією» висловлює вимога стандарту до документації на операційну систему: результат не тільки повинен бути уточнений (розробнику операційної системи це доведеться зробити в будь-якому випадку), але і явно відображений в документації на систему.

семантика умовчання

Жоден регламентує документ не може охопити всього різноманіття випадків, які можуть зустрітися на практиці, тому він неминуче про щось умалчівает3. Наприклад, в описі функції може бути сказано, що її аргумент може приймати значення з деякого діапазону, але нічого не говориться про те, яким буде результат, якщо аргументом потрапляє в цей діапазон. Очевидно, що для уникнення непорозумінь необхідно мати єдину семантику умовчання. В інформативній частині стандарту є цікава фраза: «загальноприйнята семантика умовчання - заборонено». Це твердження суперечить відомому гаслу десятирічної давності «дозволено все, що явно не заборонено». Мабуть, він настільки укорінився в свідомості громадян, що багато, навіть програмісти, не погоджуються з процитованих затвердженням стандарту. Тим часом, якщо застосування будь-якої конструкції явно не дозволено і не випливає з опису, то будь-який практикуючий програміст усвідомлює, що використання її ризиковано, і якщо вона не спрацьовує, йому не приходить в голову пред'являти претензії.

Процеси і потоки управління

Обидва цих терміну висловлюють ідею паралельності виконання. Операційна система UNIX була спочатку задумана як багато користувачів, і програми, що запускаються різними користувачами, повинні бути надійно ізольовані один від одного, щоб випадково не спотворити «чужі» дані. Ця ізоляція забезпечена тим, що програма користувача виповнюється в рамках деякого процесу, що розвивається у власному віртуальному адресному просторі. Навіть якщо в програмі є глобальні дані, при запуску її в різних процесах вони будуть автоматично «розведені» по різним адресним просторам.

Однак механізм процесів не цілком задовільний програмуючи реального часу. Прикладна програма реального часу (исполняющаяся від імені одного і того ж користувача) часто може бути природним чином представлена \u200b\u200bу вигляді паралельно виконуються частин, які називають «потоками управління» (thread). Найбільш істотне їх відміну від процесів полягає в тому, все потоки управління розвиваються в єдиному адресному просторі; цим забезпечується швидкий доступ до глобальних даними, але одночасно виникає ризик ненавмисного їх спотворення, і щоб цього не відбувалося, необхідно дотримуватися деяку дисципліну програмування. Відповідні рекомендації містяться в інформативній частині стандарту.

Потрібно підкреслити, що ідея многопоточности реалізована в багатьох операційних системах реального часу, і реалізована по-різному в тому сенсі, що кожному потоку управління відповідають різні безлічі атрибутів і інтерфейсних функцій; іноді замість терміна «потік управління» (thread) використовується термін «завдання» (task). Для того щоб уникнути непорозумінь, в стандарті підкреслюється, що мова в ньому йде виключно про потоках управління POSIX, а назви відповідних інтерфейсних функцій мають префікс pthread_ (наприклад, pthread_create (), pthread_join () і т.д.).

Відповідність стандарту. Семантика слова «відповідає»

Інтуїтивно вважається, що якщо два предмети виготовлені відповідно до одним і тим же стандартом, то вони гарантовано «сполучаються» один з одним і будуть спільно працювати в парі; саме в цьому полягає мета введення стандарту на пару (інтерфейс). Оскільки POSIX - стандарт на інтерфейс, то можна говорити про відповідність стандарту як операційної системи, так і прикладної програми.

Стандарт POSIX.1 містить кілька сотень (якщо не тисяч) вимог; вважається самоочевидним, що якщо не виконано хоча б одне з них, то система (або прикладна програма) не задовольняє стандарту. Разом з тим, до теперішнього часу написано таку кількість операційних систем класу UNIX і прикладних програм для них, що навряд чи розумно вимагати повної відповідності в зазначеному сенсі. Труднощі розробки міжнародного стандарту такого роду поглиблюються існуванням різних національних мов. Навіть якщо забути про прикладних програмах, призначених для обробки текстів на національних мовах, практично будь-яка прикладна програма повинна видавати якісь діагностичні повідомлення та / або сприймати тексти, що вводяться оператором.

• суворе відповідність стандарту POSIX.1;
• відповідність міжнародній версії POSIX.1;
• відповідність національної версії POSIX.1;
• відповідність POSIX.1 з розширеннями.

По-друге, багато інтерфейсні засоби оголошені факультативними (optional); стандарт вимагає, щоб факультативні інтерфейсні функції або відпрацьовувалися так, як наказано стандартом, або завжди повертали особливий код помилки, ENOSYS (що означає, що функція не реалізована). Факультативні засоби розбиті на кілька груп, кожна з яких відповідає певна конфігураційна константа, яка декларується (оператором #define) у відповідному заголовки; тим самим забезпечується можливість з'ясування, чи реалізована функція, на фазі компіляції.

Описаний прийом досягнення мобільності винайдений не авторами POSIX, а давно застосовується на практиці; у багатьох операційних системах конфігураційні константи застосовуються для ідентифікації самої системи або її версії. І тут стандарт не пропонує нічого принципово нового, а лише систематизує сформовану практику.

Об'єкти стандартизації та структура стандарту

Якщо говорити коротко, то об'єктами стандартизації POSIX.1 є імена і семантика. Більш конкретно, мова йде про наступне.

• Імена інтерфейсних функцій. Стандартизовано 357 функцій, причому 107 функцій взяті зі стандартних Сі-бібліотек (математичні, обробка рядків, введення / висновок і ін.); ці функції вважаються частиною стандарту POSIX.1, проте їх повний опис міститься в стандарті на мову програмування Сі.
• Імена системних типів даних. Ці імена мають суфікс _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.

При читанні стандарту іноді виникає враження, що деякі формулювання мали єдину мету: не вивести з категорії відповідають стандарту якісь прикладні програми або операційні системи. Така мета дійсно була поставлена \u200b\u200bі явно сформульована у вступі: стандарт повинен максимально враховувати сформовану практику. Однак головна мета - це все-таки забезпечення мобільності прикладних програм.

про авторe

Сергій Романюк - старший науковий співробітник Науково-дослідного інституту системних досліджень, керівник групи перекладачів стандарту POSIX. З ним можна зв'язатися по електронній пошті за адресою: [Email protected]

література

Сьогодні ми спробуємо з'ясувати, що описує стандарт POSIX. Стандарти призначені для того, щоб мій комп'ютер міг взаємодіяти з вашим. Завдяки їм, на двох схожих комп'ютерах веб-сторінки або трансляція відео в реальному часі будуть виглядати однаково.

Однак стандартні призначені для більш масштабних завдань, ніж простий обмін будь-якими даними між користувачами. Деякі стандарти визначають особливу модель, завдяки якій відкриваються можливості, значно перевершують за своїм значенням сумісність файлів або мереж. Стандарт POSIX відноситься до їх числа.

Що таке POSIX?

POSIX (вимовляється як «позікс») - це інтерфейс портативних операційних систем. Але що це означає? По-перше, потрібно позначити область дії поняття «портативність», в цьому конкретному випадку, і визначитися з поняттям «інтерфейс». Щоб з'ясувати це, необхідно відштовхуватися від того, що обидва поняття нерозривно пов'язані.

«Портативність», в контексті стандарту POSIX, відноситься до вихідного коду (не проти бінарники, які з цих самих початкових кодів збираються). Тепер з'ясуємо, що таке «інтерфейс». У програмуванні, «інтерфейс» - це взаємодія вашого коду з іншим кодом. Інтерфейс чекає від вашого коду надання певної інформації. Ваш код, в свою чергу, передбачає отримання певної інформації від інтерфейсу. Гарний приклад - функція fopen () в мові Сі. Вона очікує інформації з двох частин: шлях до файлу і режим, в якому він буде відкритий. За допомогою цих даних, операційна система повертає інший вид інформації, який називається «дескриптор файлу». Дескриптор файлу може бути використаний для читання файлу або запису в файл. Це і є інтерфейс. З усього цього випливає, що POSIX-сумісний код може бути скомпільований під будь-яку POSIX-сумісну операційну систему без серйозних змін, а значить, він буде портативним.

Список інтерфейсів, що відносяться до стандарту POSIX, знаходиться, проте, навіть незважаючи на його велику довжину, цілком можливо, що він не вичерпний. POSIX не обмежується системними викликами, він також визначає стандарти для оболонок операційних систем (Шелл, інакше - інтерфейсів командного рядка), системних утиліт, на кшталт «awk» або «echo», системних бібліотек і багато чого іншого.

Стандарт POSIX з'явився у вигляді проекту Річарда Столлман в 1985 році і в подальшому був оформлений як IEEE Std 1003.-1998. Як видно з назви, 1998 рік був роком офіційної публікації. З тих пір було випущено велику кількість доповнень і розширень до POSIX, який поступово перетворюється в ціле сімейство стандартів, формально відоме як IEEE 1003, визнане в якості міжнародного, з позначенням SO / IEC 9945, попросту зване стандарт сімейства POSIX.

Операційній системі зовсім необов'язково бути POSIX-сумісної або вже тим більше мати сертифікат POSIX, однак це дозволяє розробникам створювати додатки, інструменти і платформи, що не переписуючи код раз по раз, а лише доповнювати і підключатися до вже готового. Також зовсім не обов'язково писати POSIX-сумісний код, проте це значно покращує переносимість проектів між операційними системами. Це означає, що вміння писати код, який відповідає стандарту POSIX, є цінним саме по собі, і, безумовно, дуже корисно для кар'єри. Великі проекти, такі як Gnome або KDE, дотримуються стандарту POSIX, що гарантує їх роботу на різних операційних системах. Підсистема POSIX реалізована навіть в останніх випусках Windows. Linux, як відомо, підтримує більшість системних викликів, що відносяться до стандарту POSIX, також як і велике розширення до нього, зване «Стандартна база Linux», яка призначена для об'єднання дистрибутивів Linux в плані підтримки вихідних кодів і бінарних даних.

Сподіваюся, ми пролили світло на питання «що таке POSIX». Володієте цікавою інформацією по темі? Будь ласка, поділіться їй в коментарях.

- (IPAEng | pɒzɪks) or Portable Operating System Interface cite web | title \u003d POSIX | url \u003d http://standards.ieee.org/regauth/posix/ | work \u003d Standards | publisher \u003d IEEE] is the collective name of a family of related standards specified by the IEEE ... Wikipedia

POSIX - est le nom d une famille de standards définie depuis 1 988 par l Institute of Electrical and Electronics Engineers et formellement désignée IEEE 1003. Ces standards ont émergé d un projet de standardisation des API des logiciels destinés à ... ... Wikipédia en Français

Posix - est le nom d une famille de standards définie depuis 1988 par l IEEE et formellement désignée IEEE 1003. Ces standards ont émergé d un projet de standardisation des API des logiciels destinés à fonctionner sur des variantes du système d ... ... Wikipédia en Français

POSIX - es el acrónimo de Portable Operating System Interface; la X viene de UNIX como seña de identidad de la API. El término fue sugerido por Richard Stallman en respuesta a la demanda de la IEEE, que buscaba un nombre fácil de recordar. Una traducción ... Wikipedia Español

POSIX -, 1986 im Standard 1003.1 der IEEE niedergelegte Spezifikation für Zugriffe auf Systemfunktionen unter Unix. Sowohl Unix Sy ... Universal-Lexikon

POSIX - standartai statusas T sritis informatika apibrėžtis Standartų grupė, apibrėžianti operacinės sistemos sąsajas tarp joje veikiančių programų bei tarnybų. Pirmuosius standartus sukūrė Elektros ir elektronikos inžinierių institutas (IEEE) Linukso ... ... Enciklopedinis kompiuterijos žodynas

POSIX - es el acrónimo de Portable Operating System Interface, viniendo la X de UNIX con el significado de la herencia de la API (Se traduciría como Sistema Operativo Portable basado en UNIX). Estos son una familia de estándares de llamadas al sistema ... ... Enciclopedia Universal

POSIX - (Portable Operating System Interface based on uniX) n. collection of standards for operating systems that are based on Unix (Computers) ... English contemporary dictionary

POSIX

Posix - Das Portable Operating System Interface (POSIX [pɒsɪks]) ist ein gemeinsam von der IEEE und der Open Group für Unix entwickeltes standardisiertes Application Programming Interface, das die Schnittstelle zwischen Applikation und dem ... ... Deutsch Wikipedia

книги

• , Стівен А. Раго, У. Річард Стівенс. "UNIX. Професійне програмування" - це докладне довідковий посібник, який протягом 20 років допомагає професійним програмістам на мові С писати виключно ...
• UNIX. Професійне програмування, Стівенс У. Річард, Раго Стівен А .. Ця книга заслужено користується популярністю у серйозних програмістів у всьому світі, оскільки містить найважливішу і практичну інформацію про управління ядрами UNIX і Linux. Без цих ...

СТАНДАРТИ

Сергій Золотарьов,

Метою даної статті є спроба внести певну ясність в історію розвитку стандарту POSIX стосовно операційним системам реального часу (ОС РВ).

В якості введення: навіщо потрібна стандартизація програмного інтерфейсу?

Одним з найважливіших властивостей стандарту POSIX є те, що він визначає "стандартизований програмний інтерфейс", якого повинні дотримуватися розробники складних програмно-апаратних систем. Творці цих систем змушені стикатися з такими вимогами, як стислі терміни виходу на ринок (через жорстку конкуренцію), мінімізація витрат і прискорення повернення інвестицій. При цьому левова частка витрат, обумовлених уповільненням процесу розробки, пов'язана з тим, що програмістам доводиться "винаходити велосипед", знову і знову реалізовуючи функціональність, яка вже давно є. Але ж цього можна було б уникнути за рахунок:

Повторного використання коду з минулих і паралельних проектів;

Перенесення коду з інших ОС;

Залучення розробників з інших проектів (в тому числі з використанням інших ОС).

Все це можливо завдяки застосуванню ОС із стандартизованим API. Причому якщо в першому випадку організації досить мати певний внутрішній стандарт (що особливо характерно для фірмових ОС), то другі два випадки якраз вимагають наявності загальновизнаних стандартів - наприклад, POSIX.

Таким чином, використовуючи в якості платформи для своїх проектів POSIX-сумісну ОС, розробник отримує можливість перенести готовий код на рівні початкового тексту як зі своїх минулих або паралельних проектів, так і з проектів третіх фірм. Це не тільки істотно скорочує терміни розробки ПО, але і підвищує його якість, оскільки перевірений код завжди містить менше помилок.

Хто є хто в справі розвитку POSIX

І почнемо ми не з самого стандарту POSIX, а з упорядкування ролі організацій, що беруть участь в роботі над ним.

Перший учасник - це IEEE (Institute of Electrical and Electronics Engineers, Інститут інженерів по електриці і електроніці), громадська некомерційна асоціація професіоналів. IEEE веде свою історію з 1884 р (формально - з 1963-го), об'єднує 380 000 індивідуальних членів з 150 країн, видає третю частину технічної літератури, що стосується застосування комп'ютерів, управління, електро- та інформаційних технологій, а також понад 100 журналів, популярних в середовищі професіоналів; крім того, асоціація проводить в рік понад 300 великих конференцій. IEEE брала участь в розробці більш 900 діючих стандартів (www.ieee.ru/ieee.htm). Сьогодні цей інститут займається підготовкою, узгодженням, затвердженням, публікацією стандартів, але за своїм формальним статусом не має повноважень приймати такі документи, як міжнародні або національні стандарти. Тому термін "стандарт" в розумінні IEEE швидше означає "специфікація", що більш відповідає статусу прийнятих асоціацією документів. Відповідно до IEEE бере участь в програмах ряду міжнародних і регіональних організацій - IEC, ISO, ITU (International Telecommunication Union), ETSI (European Telecommunications Standards Institute), CENELEC (European Committee for Electrotechnical Standartization) і в національних програмах, наприклад в програмі такої організації , як ANSI.

До складу IEEE входить PASC (Portable Application Standards Committee; www.pasc.org/) - комітет асоціації, який займається розробкою сімейства стандартів POSIX. Раніше PASC був відомий як Технічний комітет з операційним системам.

Другий учасник робіт - ANSI (American National Standards Institute, Американський національний інститут стандартів; www.ansi.org) - приватна некомерційна організація, яка адмініструє і координує в США діяльність з питань стандартизації. У ній працює всього 75 чоловік, але членами ANSI є більше 1000 компаній, організацій, урядових агентств і інститутів. ANSI представляє США в двох основних міжнародних організаціях по стандартизації - ISO і IEC.

Третій учасник - ISO (International Organization for Standardization, Міжнародна організація по стандартизації; www.iso.org). Вона створена в 1946 р за рішенням Комітету з координації стандартів і Генеральної асамблеї ООН і офіційно почала роботу 23 лютого 1947 р ISO - це мережа національних інститутів по стандартизації з 146 країн (одна країна - один член ISO) з центральним секретаріатом в Женеві ( Швейцарія). Стандарти ISO розробляються в технічних комітетах, першим результатом діяльності яких є документ Draft International Standard (DIS), що перетворюється після декількох погоджень в Final Draft International Standard (FDIS). Після цього питання про схвалення даного документа виноситься на голосування; при позитивному результаті він стає міжнародним стандартом.

І наприкінці, - IEC (International Electrotechnical Commission, Міжнародна електротехнічна комісія - ІЕС; www.iec.ch/), заснована в 1906 р IEC готує і публікує міжнародні стандарти для всіх електричних, електронних і пов'язаних з ними технологій. Станом на 1 листопада 2004 р дійсними членами цієї комісії були національні комітети 64 країн. IEC видає також і рекомендації, які виходять англійською та французькою мовами і носять статус міжнародних стандартів. На їх основі розробляються регіональні та національні стандарти. За підготовку стандартів в різних областях діяльності IEC відповідають технічні комітети (ТК), в роботі яких беруть участь і національні комітети, зацікавлені в діяльності того чи іншого ТК.

IEC - ключова організація в підготовці міжнародних стандартів з інформаційних технологій. У цій області діє об'єднаний технічний комітет з інформаційних технологій - JTC 1, сформований в 1987 р відповідно до угоди між IEC і ISO. JTC1 має 17 підкомітетів, які курують все розробки - від програмного забезпечення до мов програмування, комп'ютерної графіки та редагування зображень, взаємозв'язку обладнання і методів безпеки.

Підготовка нових стандартів IEC включає кілька стадій (попередня, стадія пропозиції, підготовча, стадія технічного комітету, стадія запиту, схвалення, публікації). Якщо заплановано, що документ IEC стане тільки технічною специфікацією, а не міжнародним стандартом, переглянута версія документа надсилається до центрального офісу для видання. На вироблення заключного проекту міжнародного стандарту (FDIS) відводиться чотири місяці. Якщо його схвалять всі члени технічного комітету, він направляється в центральний офіс для публікації без стадії схвалення FDIS. Після цього FDIS потрапляє в національні комітети, які повинні затвердити його протягом двох місяців. FDIS вважається схваленим, якщо за нього проголосувало більше двох третин національних комітетів, а кількість негативних голосів не перевищує 25%. Якщо документ не схвалений, він відправляється для перегляду в технічні комітети і підкомітети. Стандарт повинен бути опублікований не пізніше ніж через два місяці після схвалення FDIS.

До вироблення та прийняття стандартів POSIX мають відношення ще кілька організацій.

Open Group - міжнародна організація по стандартизації програмного забезпечення, яка об'єднує майже 200 виробників і призначених для користувача спільнот, що працюють в області інформаційних технологій (www.opengroup.org/).OpenGroup створена в 1995 р шляхом злиття двох своїх попередників: X / Open і Open Software Foundation (OSF). Open Group спеціалізується на розробці методологій сертифікації програмного забезпечення та проведенні тестування на відповідність певним вимогам. Зокрема, Open Group займається сертифікацією для таких напрямків, як COE Platform, CORBA, LDAP, Linux Standard Base, Schools Interoperability Framework (SIF), S / MIME Gateway, Single UNIX Specification, Wireless Application Protocol Specifications (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 і Single UNIX Specification (www.opengroup.org/press/14nov02.htm).

National Institute of Standards and Technology (NIST) - федеральне агентство в складі Commerce Department's Technology Administration (www.nist.gov/public_affairs/general2.htm), засноване в США в 1901 р Завдання NIST - розробка і пропаганда стандартів і технологій з метою підвищення якості продукції. До складу NIST входить лабораторія з інформаційних технологій (Information Technology Laboratory - ITL), Одним з результатів діяльності якої є федеральні стандарти з обробки інформації (Federal Information Processing Standards - FIPS, www.opengroup.org/testing/fips/general_info.html).NIST/ITL запропонувала в 1991 р початковий набір тестів для сертифікації по POSIX в рамках FIPS PUB 151-1 1990.

Що таке POSIX?

формально термін POSIX запропонований Річардом Столлманом (Richard Stallman) як абревіатура для Portable Operating System interface for un IX (Стерпний інтерфейс операційних систем для Unix). POSIX розроблявся для UNIX-подібних операційних систем (їх перші версії ведуть свій відлік з початку 1970-х) з метою забезпечення переносимості додатків на рівні вихідних текстів.

Первісне опис інтерфейсу було опубліковано в 1986 р, тоді він називався IEEE-IX (IEEE's version of 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-1 993, 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 г. Прийнято рішення внести в основний текст стандарту перші за останні 10 років суттєві зміни, включаючи об'єднання зі стандартом 1003.2 (Shell і утиліти), так як на той час це були окремі стандарти. PASC вирішив закінчити зміни базового тексту після завершення роботи над стандартами IEEE 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q і 1003.2b.

- 2004 р Остання на сьогоднішній день редакція стандарту 1003.1 була опублікована 30 квітня і випущена під егідою Austin Common Standards Revision Group. У неї внесені зміни, що стосуються редакції стандарту 2001 Формально редакція 2004 р відома як IEEE Std 1003.1, 2004 Edition, The Open Group Technical Standard Base Specifications, Issue 6 і включає IEEE Std 1003.1-2001, IEEE Std 1003.1-2001 / Cor 1-2002 і IEEE Std 1003.1-2001 / Cor 2-2004.

Найбільш важливі стандарти POSIX для ОС РВ

Для операційних систем реального часу найбільш важливі сім специфікацій стандарту, але широку підтримку в комерційних ОС отримали тільки три:

1003.1a (OS Definition) визначає основні інтерфейси ОС, управління завданнями, сигнали, функції файлової системи і роботи з пристроями, групи користувачів, конвеєри, FIFO-буфери;

1003.1b (Realtime Extensions) описує розширення реального часу, такі, як сигнали реального часу, диспетчеризація за пріоритетами, таймери, синхронний і асинхронний ввід-висновок, семафори, колективна пам'ять, повідомлення. Спочатку (до 1993 р) цей стандарт позначався як POSIX.4;

1003.1c (Threads) визначає функції підтримки потоків (ниток) - управління потоками, атрибути потоків, м'ютекси, диспетчеризацію. Спочатку значився як POSIX.4a.

Крім зазначених стандартів важливими для ОС РВ є такі нормативні документи, які були реалізовані в рамках роботи над проектом Std 1003.1-2001:

IEEE 1003.1d-1999. Додаткові розширення реального часу. Спочатку значився як POSIX.4b;

IEEE 1003.1j-2000. Покращені (advanced) розширення реального часу;

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 "Standard for Test Methods for Measuring Conformance to POSIX" Draft 10, May 3, 1989. В 1993 р NIST закінчив програму тестування (POSIX Testing Program) для FIPS 151-1 і почав програму для FIPS 151 -2 (www.itl.nist.gov/fipspubs/fip151-2.htm).FIPS 151-2 адаптував "Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)," що є стандартом ISO / IEC 9945-1: 1990. Набори тестів для FIPS 151-2 грунтувалися на IEEE 2003.1-1992 "Standard for Test Methods for Measuring Conformance to POSIX".

NIST розрізняє дві методології сертифікації: самосертификация (self-certification) і сертифікація акредитованими в IEEE тестовими лабораторіями (Accredited POSIX Testing Laboratories - 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. Ті ж функції з 1 січня 1998 го взяла на себе Асоціація по стандартизації IEEE (IEEE-SA), і також на основі FIPS 151-2.

У 2003 р IEEE-SA і Open Group оголосили про початок нової спільної програми по сертифікації останніх версій POSIX, починаючи з IEEE 1003.1 (tm) 2001. Зараз Open Group має кілька наборів тестів, які покривають 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) - набір conformance-тестів для системних інтерфейсів IEEE Std 1003.1-1990;

VSPSE54 (www.opengroup.org/testing/testsuites/VSPSE54.htm) - набір conformance-тестів для IEEE Std 1003.13-1998 Profile PSE54 (багатоцільове реальний час);

VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm) - набір conformance-тестів для системних інтерфейсів IEEE Std 1003.1-2003 (тільки обов'язкові частини);

VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpcts2003.htm) - набір conformance-тестів для IEEE Std 1003.1-2003 (shell and utilities - тільки обов'язкові частини).

Крім того, Open Group розробила тести для стандартів POSIX Realtime і профілю стандартів Embedded POSIX. Набір тестів для POSIX Realtime (www.opengroup.org/testing/testsuites/realtime.html) включає наступні тести:

IEEE POSIX 1003.1b-1 993 / 1003.1i-тисяча дев'ятсот дев'яносто-п'ять Realtime extension and IEEE POSIX 1003.1,2003 Edition;

IEEE Std POSIX 1003.1c-1995 Threads (pthreads) extension and IEEE POSIX 1003.1,2003 Edition;

IEEE POSIX 1003.1d-1999 Additional Realtime Extension and IEEE POSIX 1003.1,2003 Edition;

IEEE POSIX 1003.1j-2000 Advanced Realtime Extension and IEEE POSIX 1003.1,2003 Edition;

IEEE POSIX 1003.1q-2000 Trace and IEEE POSIX 1003.1,2003 Edition and IEEE POSIX 1003.1,2003 Edition;

Набір тестів профілю стандартів Embedded POSIX (www.opengroup.org/testing/testsuites/embedded.html) включає наступні тести:

IEEE POSIX 1003.1-1990 (5310 тестів);

IEEE POSIX 1003.1b-1993 / 1003.1i-1995 Realtime extension (1430 тестів);

IEEE Std POSIX 1003.1c-тисяча дев'ятсот дев'яносто п'ять Threads (pthreads) extension (одна тисяча двісті тридцять дві тесту);

IEEE POSIX 1003.13-1998 Profile 52.

Трохи про плутанину в термінології

Стосовно до групи стандартів POSIX в англійській мові часто використовуються не один, а цілих три терміни. На жаль, вони подібні за значенням і часто перекладаються однаково, що вносить певну плутанину. Терміни ці такі:

Сompatibility (буквально - "сумісність");

Сompliance (буквально - "відповідність");

Сonformance (буквально - "узгодженість").

Перший термін стосовно POSIX формально не визначений. Другий означає, що організація - виробник програмного продукту самостійно заявляє про те, що продукт цей (повністю або частково) відповідає перерахованим стандартам NIST-PCTS. Третій термін має на увазі, що програмний продукт пройшов встановлену систему тестів або за допомогою акредитованої лабораторії, або в рамках Open Group і на це є документальне підтвердження (так зване Conformance Statement). Далі в тексті статті всюди будуть приводитися оригінали термінів, щоб виключити неоднозначність.

Сертифіковані ОС РВ

Якщо дотримуватися строгих правил, що вимагають, щоб дані про сертифікованої ОС РВ були опубліковані в офіційному реєстрі і тестування проводилися за рівнем conformance, То в даний час є всього дві сертифіковані ОС РВ (дані наведені в хронологічному порядку):

- LynxOS v.3 (Продукт фірми Lynx Real-Time Systems, яка зараз називається LynuxWorks, Inc., www.lynuxworks.com) призначена для розробки ПО вбудованих систем, що функціонують в режимі жорсткого реального часу, виробниками комплектного і телекомунікаційного устаткування, зокрема виробниками бортових систем військового застосування. Розробка може здійснюватися як на самій цільовій системі (self-hosted), так і на інструментальному комп'ютері (host), готове ПЗ призначене для роботи на цільовій системі (target). LynxOS v.3 сертифікована на узгодженість (Conformance)стандарту POSIX на платформі Intel і PowerPC. Інформацію про це можна знайти на сайті IEEE http://standards.ieee.org/regauth/posix/posix2.html.LynxOS сертифікована по POSIX 1003.1-1996 компанією Mindcraft, що є IEEE POSIX Accredited POSIX Testing Laboratory по набору тестів NIST FIPS 151- 2 Conformance Test Suite. Номер документа, що підтверджує сертифікацію: Reference File: IP-2LYX002, Reference File: IP-2LYX001.

- INTEGRITY v.5 (Продукт фірми Green Hills Software, www.ghs.com) сертифікована на узгодженість (Conformance) по POSIX 1003.1-2003, System Interfaces для архітектури 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) сертифікована на відповідність (Compliance) по POSIX 1003.1-1988 для платформи Intel компанією DataFocus Incorporated. Тестування проводилося 13 вересня 1993 року, дата видачі документа - 1 листопада 1993 г. Набір тестів NIST PCTS 151-1, версія 1.1.

QNX Neutrino (версія 6.3) відповідає (complies to) наступним стандартам сімейства 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, планує також сертифікацію (conformance) QNX Neutrino за деякими з цих стандартів; роботи заплановані на 2005 р (www.qnx.com/news/pr_959_1.html).

література

1. IEEE Standards Association Operation Manual. IEEE, October 2004.

2. Kevin M. Obeland. POSIX in Real-Time, Embedded Systems Programming, 2001..

3. IEEE / ANSI Standard 1003.1: Information Technology - (POSIX) - Part1: System Application: Program Interface (API).

4. Gallmeister B. O. Programming for the Real World, POSIX.4 Sebastopol, CA: O'Reilly & Associates, 1995.

5. National Institute of Standards and Technology, PCTS: 151-2, POSIX Test Suite.

6. POSIX: Certified by IEEE and The Open Group. Certified Policy. The Open Group, October 21, 2003 Revision 1.1.