Главная / Проблемы / Unix стандартизация операционных систем и posix. Стандарты операционных систем реального времени

Unix стандартизация операционных систем и posix. Стандарты операционных систем реального времени

О стандартах вообще

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

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

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

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

Может быть, на это мнение не следовало бы обращать внимания, если бы не два обстоятельства:

(1) его высказывают практики, то есть именно те, кто «выдает программную продукцию»;

(2) приведенная выше аргументация была обнаружена автором данной статьи в одной из публикаций в 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 была изначально задумана как многопользовательская, и программы, запускаемые разными пользователями, должны быть надежно изолированы друг от друга, чтобы случайно не исказить «чужие» данные. Эта изоляция обеспечена тем, что программа пользователя исполняется в рамках некоторого процесса, развивающегося в собственном виртуальном адресном пространстве. Даже если в программе есть глобальные данные, при запуске ее в разных процессах они будут автоматически «разведены» по разным адресным пространствам.

Однако механизм процессов не вполне удовлетворителен при программировании задач реального времени. Прикладная программа реального времени (исполняющаяся от имени одного и того же пользователя) часто может быть естественным образом представлена в виде параллельно исполняющихся частей, которые называют «потоками управления» (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.

При чтении стандарта иногда возникает впечатление, что некоторые формулировки имели единственную цель: не вывести из категории удовлетворяющих стандарту какие-то прикладные программы или операционные системы. Такая цель действительно была поставлена и явно сформулирована во Введении: стандарт должен в максимальной степени учитывать сложившуюся практику. Однако главная цель - это все-таки обеспечение мобильности прикладных программ.

Об авторe

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

1 Следует добавить, что работа над стандартом продолжается в течение многих лет; выявляются новые вопросы, и они либо включаются в одну из имеющихся частей, либо оформляются в виде отдельной части, которая впоследствии может быть аннулирована. Так произошло, например, с интерфейсными средствами реального времени, которые вначале были объявлены как POSIX.4, а впоследствии включены в POSIX.1.

2 IEEE - организация, в которой разработан стандарт POSIX.

3 Здесь «умолчание» означает silent, а не default; речь идет не о каких-то подразумеваемых значениях, которые на самом деле декларированы, а об отcутствии упоминаний вообще.

4 Перевод стандарта на русский язык будет опубликован в начале 2000 года.

Литература

International Standard ISO/IEC 9945-1 (ANSI/IEEE Std 1003.1) Second Edition. 1996-07-12. Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) .

М.И.Беляков, Ю.И.Рабовер, А.Л.Фридман. Мобильная операционная система. Справочник. Москва, «Радио и связь», 1991.

ISO/IEC 9899: 1990, Programming languages - C.

Раздел 1	- Введение
Раздел 2	- Терминология и определения
Раздел 3	- Функции управления процессами (создание, замена образа, завершение) и сигналами (управление масками, реагирование на сигналы)
Раздел 4	- Идентификация (процессов, пользователей, системы, терминала), опрос времен, затраченных на исполнение процесса, опрос переменных окружения.
Раздел 5	- Управление файлами и каталогами
Раздел 6	- Функции ввода и вывода
Раздел 7	- Функции управления терминалом
Раздел 8	- Функции, заимствованные из стандарта на язык Си
Раздел 9	- Доступ к базам данных пользователей и групп пользователей
Раздел 10	- Форматы данных для архивирования и обмена (tar и cpio)
Раздел 11	- Средства синхронизации: семафоры, мьютексы и переменные условий
Раздел 12	- Функции управления памятью: закрепление и открепление адресного пространства процесса, отображение файлов на память, защита памяти, разделяемая память
Раздел 13	- Функции, связанные с планированием процессов и потоков управления
Раздел 14	- Управление часами и таймерами
Раздел 15	- Управление очередями сообщений
Раздел 16	- Базовые функции, относящиеся к потокам управления
Раздел 17	- Индивидуальные данные потоков управления (thread-specific data)
Раздел 18	- Средства уничтожения потоков управления

СТАНДАРТЫ

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

Целью данной статьи является попытка внести определенную ясность в историю развития стандарта 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) как аббревиатура для P ortable O perating S ystem interface for unIX (переносимый интерфейс операционных систем для 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-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 г. Принято решение внести в основной текст стандарта первые за последние 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-1993/1003.1i-1995 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-1995 Threads (pthreads) extension (1232 теста);

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.

ПО ) - задача исключительной важности и сложности; в наше время это обстоятельство едва ли нуждается в пространных обоснованиях. Один из общепринятых способов повышения мобильности ПО - стандартизация окружения приложений: предоставляемых программных интерфейсов, утилит и т.п. На уровне системных сервисов подобное окружение описывает стандарт POSIX ( Portable Operating System Interface - мобильный интерфейс операционной системы); название предложено известным специалистом, основателем Фонда свободного программного обеспечения Ричардом Столмэном.

Мы будем рассматривать наиболее современную из доступных версий стандарта POSIX , в редакции 2003 г., которую можно назвать "стандартом втройне", а именно: стандартом IEEE Std 1003.1, Техническим стандартом Open Group и (см. [ 6 ]), что для нас важнее всего, международным стандартом ISO /IEC 9945 (см. [ 1 ] , [ 2 ] , [ 3 ] , [ 4 ]).

История создания этой версии такова. В начале 1998 г. представители трех организаций - Комитета по стандартам мобильных приложений Института инженеров по электротехнике и электронике, Open Group и рабочей группы 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-интерфейса к системным сервисам;
описание интерфейса к системным сервисам на уровне командного языка и служебных программ ;
детальное разъяснение положений стандарта, обоснование принятых решений.

Далее в ISO , IEEE и Open Group с большей или меньшей скоростью (в 2001-2002 гг.) прошло формальное утверждение нового стандарта POSIX . Тем временем накапливались относительно мелкие исправления, учтенные в редакции 2003-го года.

С развитием стандарта расширялась и трактовка термина " POSIX ". Первоначально он относился к документу IEEE Std 1003.1-1988, описывавшему прикладной программный интерфейс ОС класса Unix. После стандартизации интерфейса на уровне командного языка и служебных программ более правильно понимать под словом " POSIX " стандарт в целом, обозначая перечисленные выше части 2 и 3 через POSIX .1 и POSIX .2 в соответствии с нумерацией документов IEEE и ISO /IEC.

Основные идеи стандарта POSIX

Стандарт POSIX описывает множество базовых, системных сервисов, необходимых для функционирования прикладных программ. Доступ к ним предоставляется посредством интерфейса, специфицированного для языка C, командного языка и общеупотребительных служебных программ.

У каждого интерфейса есть две стороны: вызывающая и вызываемая. Стандарт POSIX ориентирован в первую очередь на вызывающую. Его цель - сделать приложения мобильными на уровне исходного языка . Это значит, в частности, что при переносе C-программ на другую операционную платформу потребуется перекомпиляция. О мобильности выполнимых программ и/или объектных файлов речь не идет.

Стандарт POSIX отнюдь не ограничен рамками Unix-среды . Существуют операционные системы (ОС) "независимого происхождения" (например, системы реального времени ), предоставляющие необходимые сервисы и тем самым поддерживающие выполнение POSIX -совместимых приложений. Можно утверждать, что следование стандарту POSIX облегчает перенос приложений практически на любую сколько-нибудь распространенную операционную платформу. Дополнительные усилия по повышению мобильности, прилагаемые на этапе разработки, безусловно, окупятся.

Определяя интерфейс к системным сервисам, POSIX оставляет за рамками рассмотрения их реализацию. В частности, не различаются системные вызовы и библиотечные функции . Не являются объектом стандартизации средства администрирования , аппаратные ограничения и функции, необходимые только суперпользователю , что еще раз подчеркивает направленность стандарта

Сегодня мы попытаемся выяснить, что описывает стандарт 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». Обладаете интересной информацией по теме? Пожалуйста, поделитесь ей в комментариях.

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) – комитет ассоциации, который занимается разработкой семейства стандартов POSIX (www.pasc.org/). Ранее PASC был известен как Технический комитет по операционным системам.

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

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

И наконец, – IEC (International Electrotechnical Commission, Международная электротехническая комиссия – МЭК), основанная в 1906 г. IEC готовит и публикует международные стандарты для всех электрических, электронных и связанных с ними технологий (www.iec.ch/). На 1 ноября 2004 г. действительными членами этой комиссии являлись национальные комитеты 64 стран. IEC издает также и рекомендации, которые выходят на английском и французском языках и носят статус международных стандартов. На их основе разрабатываются региональные и национальные стандарты. За подготовку стандартов в различных областях деятельности IEC отвечают технические комитеты (ТК), в работе которых принимают участие и национальные комитеты, заинтересованные в деятельности того или иного ТК.

IEC – ключевая организация в подготовке международных стандартов по информационным технологиям. В этой области действует объединенный технический комитет по информационным технологиям – JTC 1, сформированный в 1987 г. в соответствии с соглашением между IEC и ISO. JTC1 имеет 17 подкомитетов, курирующих все разработки – от программного обеспечения до языков программирования, компьютерной графики и редактирования изображений, взаимосвязи оборудования и методов безопасности.

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

Open Group – международная организация по стандартизации программного обеспечения, которая объединяет почти 200 производителей и пользовательских сообществ, работающих в области информационных технологий (www.opengroup.org/). Open Group создана в 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/).

Austin Common Standards Revision Group (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) как аббревиатура для P ortable O perating S ystem interface for unIX (переносимый интерфейс операционных систем для 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

Первая версия спецификации 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 г.

Принято решение внести в основной текст стандарта первые за последние 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, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21 ), но широкую поддержку в коммерческих ОС получили только три:

1003.1a (OS Definition) определяет основные интерфейсы ОС, управление заданиями, сигналы, функции файловой системы и работы с устройствами, группы пользователей, конвейеры, FIFO-буферы;
1003.1b (Realtime Extensions) описывает расширения реального времени, такие, как сигналы реального времени, диспетчеризация по приоритетам, таймеры, синхронный и асинхронный ввод-вывод, семафоры, разделяемая память, сообщения. Первоначально (до 1993 г.) этот стандарт обозначался как POSIX.4.
1003.1c (Threads) определяет функции поддержки потоков (нитей) – управление потоками, атрибуты потоков, мьютексы, диспетчеризация. Первоначально обозначался как POSIX.4a.

IEEE 1003.1d-1999. Дополнительные расширения реального времени. Первоначально обозначался как POSIX.4b;
IEEE 1003.1j-2000. Улучшенные (advanced) расширения реального времени;
IEEE 1003.1q-2000. Трассировка.

Процедура сертификации

В 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™ 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 – только обязательные части).

IEEE POSIX 1003.1b-1993/1003.1i-1995 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-1995 Threads (pthreads) extension (1232 теста);
IEEE POSIX 1003.13-1998 Profile 52.

Немного о путанице в терминологии

с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).

Литература

IEEE Standards Association Operation Manual. IEEE, October 2004.
Kevin M. Obeland. POSIX in Real-Time, Embedded Systems Programming, 2001.
IEEE/ANSI Standard 1003.1: Information Technology – (POSIX) – Part1: System Application: Program Interface (API).
Gallmeister, B. O. Programming for the Real World, POSIX.4 Sebastopol, CA: O’Reilly & Associates, 1995.
National Institute of Standards and Technology, PCTS:151-2, POSIX Test Suite.
POSIX: Certified by IEEE and The Open Group. Certified Policy. The Open Group, October 21, 2003, Revision 1.1.

Unix стандартизация операционных систем и posix. Стандарты операционных систем реального времени

О стандартах вообще

Назначение и «сверхзадача» стандарта POSIX

О семантике

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

Объекты стандартизации и структура стандарта

Заключение

Об авторe

Литература

Основные идеи стандарта POSIX

Что такое POSIX?

POSIX и ОС РВ: попытка систематизации

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

Кто есть кто в деле развития POSIX

Что такое POSIX?

История развития стандарта POSIX

Наиболее важные стандарты POSIX для ОС РВ

Процедура сертификации

Немного о путанице в терминологии

Сертифицированные ОС РВ

POSIX и операционная система QNX

Восстановление пароля