POSIX и ОС РВ: попытка систематизации. Основные понятия и идеи стандарта POSIX

Предмет: Операционные системы.
Вопрос: №8

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

Принципы построения ОС:

1.) Принцип модульности – под модулем в общем случае понимают функционально законченный элемент системы, выполненный в соответствии с принятыми межмодульными интерфейсами. По своему определению модуль предполагает возможность легкой замены его на другой при наличии заданных интерфейсов. В значительной степени разделение системы на модули определяется используемым методом проектирования ОС (снизу вверх или наоборот).

Особое значение при построение ОС имеют привилегированные, повторно входимые и реентерабельные модули (реентабель-ность – дословно повторновходимость; специальный термин для обозначения работоспособности программы; свойство программы корректно выполняться при рекурсивном (возвращаемом) вызове из прерывания).

Наибольший эффект от использования данного принципа достижим в случае одновременного распространения данного принципа на ОС, прикладные программы и аппаратуру.

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

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

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

5.) Принцип виртуализации: построение виртуальных ресурсов, их распределение и использование в настоящее время применяется практически в любой ОС. Этот принцип позволяет представить структуру системы в виде определенного набора планировщиков процессов и распредели-телей ресурсов (мониторов) и использовать единую централизованную схему распреде-ления ресурсов.

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

— единообразная по логике работы виртуаль-ная память практически неограниченного объема.

— произвольное количество виртуальных процессоров, способных работать парал-лельно и взаимодействовать во время рабо-ты.

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

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

6.) Принцип независимости программ от внешних устройств: этот принцип реализу-ется сейчас в подавляющем большинстве ОС общего применения. Впервые наиболее последовательно данный принцип был реализован в ОС UNIX. Реализован он и в большинстве современных ОС для ПК. Этот принцип заключается в том, что связь программ с конкретными устройствами производится не на уровне трансляции программы, а в период планирования ее исполнения. В результате перекомпиляция при работе программы с новым устройством, на котором располагаются данные, не требуется.

7.) Принцип совместимости: одним из аспектов совместимости является способ-ность ОС выполнять программы, написан-ные для других ОС или для более ранних версий данной ОС, а также для другой аппаратной платформы. Необходимо разделять вопросы двоичной совмести-мости и совместимости на уровне исходных текстов приложений.

Двоичная совместимость достигается в том случае, когда можно взять исполняемую программу и запустить ее на выполнение на другой ОС. Для этого необходимы совместимость на уровне команд процессора, и совместимость на уровне системных вызовов, и даже на уровне библиотечных вызовов, если они являются динамически связываемыми.

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

Гораздо сложнее достичь двоичной совместимости между процессорами, основанными на разных архитектурах. Для того чтобы один компьютер выполнял программы другого (например, программу для ПК типа IBM PC желательно выполнить на ПК типа Macintosh фирмы Apple), этот компьютер должен работать с машинными командами, которые ему изначально непо-нятны. В таком случае процессор типа 680×0 (или PowerPC) должен исполнять двоичный код, предназначенный для процессора i80x86. Процессор 80×86 имеет свои собственные дешифратор команд, регистры и внутреннюю архитектуру. Процессор 680×0 не понимает двоичный код 80×86, поэтому он должен выбрать каждую коман-ду, декодировать ее, чтобы определить, для

чего она предназначена, а затем выполнить эквивалентную подпрограмму, написанную для 680×0.

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

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

9.) Принцип мобильности: операционная система относительно легко должна перено-

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

— большая часть ОС должна быть выпол-нена на языке, имеющемся на всех системах, на которые планируется в даль-нейшем ее переносить. Это, прежде всего, означает, что ОС должна быть написана на языке высокого уровня, предпочтительно стандартизованном, например на языке С. Программа, написанная на ассемблере, не является в общем случае переносимой.

— важно минимизировать или, если возмож-но, исключить те части кода, которые непосредственно взаимодействуют с аппаратными средствами. Зависимость от аппаратуры может иметь много форм. Некоторые очевидные формы зависимости включают прямое манипулирование регистрами и другими аппаратными средст-вами. Наконец, если аппаратно-зависимый код не может быть полностью исключен, то он должен быть изолирован в нескольких хорошо локализуемых модулях. Аппаратно-зависимый код не должен быть распределен по всей системе. Например, можно спрятать аппаратно-зависимую структуру в программ-мно задаваемые данные абстрактного типа.

Введение стандартов POSIX преследовало цель обеспечить переносимость создава-емого программного обеспечения.

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

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

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

Что такое POSIX : платформенно-незави-симый системный интерфейс для компьюте-рного окружения POSIX (Portable Operating System Interface for Computer Environments) – это стандарт IEEE(Institute of Electrical and Electronics Engineers − институт инженеров по электротехнике и радиоэлектронике.), описывающий системные интерфейсы для открытых ОС, в том числе оболочки, утилиты и инструментарии. Помимо этого, согласно POSIX, стандартизированными являются задачи обеспечения безопасно-сти, задачи реального времени, процессы администрирования, сетевые функции и обработка транзакций. Стандарт базируется на UNIX-системах, но допускает реализацию и в других ОС. POSIX возник как попытка всемирно известной организации IEEE пропагандировать переносимость прило-жений в UNIX-средах путем разработки абстрактного, платформенно-независимого стандарта. Например, известная ОС реального времени QNX соответствует спецификациям этого стандарта.

Этот стандарт подробно описывает систему виртуальной памяти VMS (Virtual Memory System,), многозадачность МРЕ (Multi-Process Executing) и технологию переноса операционных систем CTOS (An Operating System produced Convergent Technology …). Таким образом, на самом деле POSIX представляет собой множество стандартов, именуемых POSIX.I –POSIX.12. Следует также особо отметить, что в POSIX.1 предполагается язык С в качестве основного

языка описания системных функций API.

Таким образом, программы, написанные с соблюдением данных стандартов, будут одинаково выполняться на всех POSIX-совместимых системах. Однако стандарт в некоторых случаях носит лишь рекомен-дательный характер. Часть стандартов описана очень строго, тогда как другая часть только поверхностно раскрывает основные требования.

Реализации POSIX API на уровне операционной системы различны. Если UNIX-системы в своем абсолютном большинстве изначально соответствуют спецификациям IEEE Standard 1003.1-1990, то WinAPI не является POSIX-совместимым. Однако для поддержки данного стандарта в операционной системе MS Windows NT введен специальный модуль поддержки POSIX API, работающий на уровне привилегий пользовательских процессов.

Данный модуль обеспечивает конвертацию и передачу вызовов из пользовательской программы к ядру системы и обратно, работая с ядром через Win API. Прочие приложения, созданные с использованием WinAPI, могут передавать информацию POSIX-приложениям через стандартные механизмы потоков ввода/вывода (stdin, stdout).

Нет похожих постов...

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

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

(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 (portable operating system interface) – стандарт, описывающий интерфейс между операционной системой и прикладной программой. Цель создания этого стандарта – обеспечение совместимости unix-like операционных систем, а также переносимости программ на уровне исходного кода. Однако, стандарт POSIX может использоваться не только unix системами. Название POSIX было предложено Ричардом Столлманом. Произносится как «позикс» — интерфейс переносимых операционных систем Unix.

Немного истории

Первый вариант стандарта POSIX был IEEE Std 1003. Он был выпущен в 1988 году и определял интерфейс между языком программирования Си и оболочкой ядра unix-like систем.

В 1990 году была выпущена новая версия IEEE Std 1003.2. По сравнению с первым вариантом в новом документе были внесены незначительные изменения.

В 1992 году был выпущен двухтомный стандарт IEEE Std 1003.2. В документе описывался интерпретатор команд и более сотни утилит.

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

В 1995 году вышел очередной стандарт, посвященный потокам, а документ версии 1996 года был своеобразным дополнением предыдущих версий.

Стандарт POSIX 1999 года описывал дополнительные расширения реального времени.

В 2001 году вышел стандарт, объединяющий в себе все предыдущие версии. Было принято решение использовать его как основу для принятия стандартов в будущем.

Сегодня используется версия POSIX.1, утвержденная в 2008 году.

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

Согласно задокументированных положениям, для корректного взаимодействия с приложениями ОС должна иметь такие компоненты:

• сетевые средства;
• средства разработки;
• потоки управления;
• средства реального времени;
• пакетные сервисы;
• заголовочные файлы;
• математические интерфейсы;
• унаследованные интерфейсы.

Признаки операционных систем, соответствующих стандартам POSIX

• разграничение прав пользователей и групп, а также суперпользователя root с привилегированными правами;
• наличие древовидной файловой системы, которая имеет единый корень /;
• система и программные пакеты предоставляются в виде текстовых файлов – то есть, конфигурации файлов можно изменить простым редактированием;
• единый API программирования языка C;
• единый стандарт консольных утилита и команд (POSIX 2).

К сертифицированным согласно POSIX стандарту операционным системам относятся: IBM AIX, UnixWare, Solaris, IRIX, QNX, LynxOS, Mac OS X. Полностью совместимые с одной из версий POSIX-стандарта являются такие ОС как Minix, различные ответвления BSD, OpenSolaris, VxWorks, OpenWMS. Что касается дистрибутивов Linux, то большинство из них соответствует стандарте LSB (Linux Standart Base), который в свою очередь опирается на POSIX.

Стандарт POSIX в редакции 2003-го года - весьма обширный, многогранный документ, где подробно рассматриваются следующие категории системных компонентов:

средства разработки;

сетевые средства;

средства реального времени;

потоки управления;

математические интерфейсы;

пакетные сервисы;

заголовочные файлы;

унаследованные интерфейсы.

Именно такой (на верхнем уровне, далеко не полный) репертуар должна предоставлять операционная система для работы приложения.

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

Реализация (операционная система), соответствующая стандарту POSIX, должна поддерживать все обязательные служебные программы, функции, заголовочные файлы с обеспечением специфицированного в стандарте поведения. Константа _POSIX_VERSION имеет значение 200112L.

ОС может предоставлять возможности, помеченные в стандарте в качестве дополнительных, а также содержать нестандартные функции. Если утверждается, что поддерживается некоторое расширение, это должно производиться непротиворечивым образом, для всех необходимых частей и так, как описано в стандарте.

В заголовочном файле следует определить константы, соответствующие поддерживаемым необязательным возможностям (например, константа _POSIX2_C_DEV обслуживает средства разработки на языке C). Анализируя эти константы во время компиляции, приложение выяснит возможности используемой ОС и подстроится под них. Аналогичные действия на этапе выполнения могут быть выполнены с помощью функции sysconf() и/или служебной программы getconf.

Для минимизации размеров ОС и приложений стандартом POSIX предусмотрена весьма мелкая гранулярность необязательных возможностей (всего их сорок). С другой стороны, проведено объединение взаимосвязанных необязательных возможностей в группы, что во многих случаях избавляет от анализа большого числа опций. Группы эти таковы:

шифрование;

средства реального времени;

продвинутые средства реального времени;

потоки реального времени;

продвинутые потоки реального времени;

трассировка;

• унаследованные возможности.

Например, в группу "средства реального времени" (_XOPEN_REALTIME) входят возможности четырнадцати видов, в том числе планирование на основе приоритетов, асинхронный ввод/вывод, семафоры, таймеры и т.п.

Версия ОС Linux, на которой готовился текст данного курса, выдавала следующие значения некоторых конфигурационных констант (см. листинг 1.1).

$ getconf _POSIX_VERSION

$ getconf POSIX2_C_DEV

$ getconf _XOPEN_REALTIME

$ getconf _POSIX_TRACE

Листинг 1.1. Результат применения утилиты getconf к одной из версий ОС Linux. (html , txt )

Это значит, что поддерживается устаревшая версия стандарта POSIX, среди прочих присутствуют средства разработки и возможности реального времени; средства трассировки отсутствуют.

В документации на ОС должны быть отражены вопросы соответствия стандарту POSIX, описаны поддерживаемые дополнительные и нестандартные возможности.

Для приложений понятие соответствия стандарту POSIX богаче нюансами. Предусмотрено строгое соответствие, главный отличительный признак которого - ограничение круга используемых возможностей рамками стандарта. Рассматривается и соответствие с применением расширений; в этом случае документация на приложение должна содержать описание требуемых нестандартных возможностей. Желательно, чтобы используемые расширения POSIX-возможностей описывались международными и/или национальными стандартами.

(Отметим, что для реализации понятие строгого POSIX-соответствия бессмысленно хотя бы по той причине, что не бывает операционных систем без средств администрирования, а они не описываются данным стандартом.)

Профилем будем называть набор опций, описывающих необязательные возможности. Соответствие профилю означает соответствие стандарту POSIX и поддержку заданных возможностей. Разумным образом выбранные профили позволяют учитывать потребности представительных классов пользователей и/или приложений.

Допускается существование "подпрофилей", описывающих подмножества стандартных возможностей. Реализация, соответствующая подпрофилю, может функционировать на аппаратных платформах с ограниченными ресурсами и/или обслуживать нужды специфических приложений.

К числу важнейших принадлежат понятия, описывающие поведение реализации в различных ситуациях. Для многих корректных ситуаций поведение бывает неспецифицированным, а значит, мобильное приложение не должно полагаться на совпадение поведения разных реализаций. Для некорректных ситуаций поведение может быть неопределенным; приложению не только не следует полагаться на определенный характер подобного поведения - оно не должно совершать некорректных действий, вызывающих неопределенное поведение.

Еще один близкий термин, "поведение, зависящее от реализации", дополнительно означает, что поведение реализации необходимо документировать.

Стандарт POSIX - это существующий много лет, развивающийся организм, в котором с каждой новой редакцией что-то появляется, а что-то утрачивается. Устаревшими называются возможности, которые еще поддерживаются различными реализациями, но в будущем они, вероятно, отомрут. Новые приложения не должны их использовать; для каждой из них стандартом предусмотрена адекватная по функциональности современная замена.

Более ограниченный смысл придан термину "унаследованный": он описывает устаревшие необязательные возможности, которых, разумеется, следует избегать в новых приложениях.

Обеспечение мобильности (переносимости, портабельности) программного обеспечения (ПО) - задача исключительной важности и сложности; в наше время это обстоятельство едва ли нуждается в пространных обоснованиях. Один из общепринятых способов повышения мобильности ПО - стандартизация окружения приложений: предоставляемых программных интерфейсов, утилит и т.п. На уровне системных сервисов подобное окружение описывает стандарт POSIX (Portable Operating System Interface - мобильный интерфейс операционной системы); название предложено известным специалистом, основателем Фонда свободного программного обеспечения Ричардом Столмэном. Мы будем рассматривать наиболее современную из доступных версий стандарта POSIX, в редакции 2003 г., которую можно назвать "стандартом втройне", а именно: стандартом IEEE Std 1003.1, Техническим стандартом Open Group и (см. , что для нас важнее всего, международным стандартом ISO/IEC 9945 (см. , , , ). История создания этой версии такова. В начале 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 нейтрален по отношению к системной архитектуре и разрядности процессора. Это очень важный аспект мобильности приложений. Ориентация на международный стандарт языка C определила не только стиль описания функций, но и, до некоторой степени, направление развития спецификаций POSIX в плане синхронизации обоих стандартов. Как известно в утвержденной в 1999 г. редакции спецификаций языка C (см. ) узаконен комплексный тип данных, что вызвало соответствующее пополнение POSIX-функций. В стандарте POSIX проведено разделение на обязательные и дополнительные функции, причем обязательное ядро сделано по возможности компактным. Разумеется, особое внимание уделяется способам реализации стандартизуемых функций как в "классической" Unix-среде, так и на других операционных платформах, в сетевых и распределенных конфигурациях. Разработчики новой версии стандарта POSIX очень бережно отнеслись и к его предыстории, и к предыстории Unix-систем, и, главное, к приложениям, удовлетворявшим более ранним версиям стандарта. Существующие интерфейсы старались сохранять; в процессе развития соблюдался принцип обратной совместимости ; новые интерфейсы добавлялись так, чтобы они не конфликтовали со старыми. Полностью избежать внесения изменений в приложения не удалось по вполне понятным причинам: потребовалось устранить противоречия между разными исходными спецификациями, а также отказаться от поддержки "традиционного" варианта языка C и перейти на его международный стандарт.

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

Стандарт POSIX в редакции 2003-го года - весьма обширный, многогранный документ, где подробно рассматриваются следующие категории системных компонентов:

средства разработки ;

сетевые средства ;

средства реального времени ;

потоки управления ;

математические интерфейсы ;

пакетные сервисы ;

заголовочные файлы ;

унаследованные интерфейсы.

Именно такой (на верхнем уровне, далеко не полный) репертуар должна предоставлять операционная система для работы приложения. Важнейшим является понятие соответствия стандарту POSIX . Мы уже отмечали, что всякий интерфейс располагает двумя сторонами: вызывающей и вызываемой. Две стороны есть и у POSIX-соответствия: соответствие реализации (операционной системы) и приложения. Реализация (операционная система), соответствующая стандарту POSIX, должна поддерживать все обязательные служебные программы, функции, заголовочные файлы с обеспечением специфицированного в стандарте поведения . Константа _POSIX_VERSION имеет значение 200112L . ОС может предоставлять возможности, помеченные в стандарте в качестве дополнительных, а также содержать нестандартные функции. Если утверждается, что поддерживается некоторое расширение, это должно производиться непротиворечивым образом, для всех необходимых частей и так, как описано в стандарте. В заголовочном файле следует определить константы, соответствующие поддерживаемым необязательным возможностям (например, константа _POSIX2_C_DEV обслуживает средства разработки на языке C). Анализируя эти константы во время компиляции, приложение выяснит возможности используемой ОС и подстроится под них. Аналогичные действия на этапе выполнения могут быть выполнены с помощью функции sysconf() и/или служебной программы getconf. Для минимизации размеров ОС и приложений стандартом POSIX предусмотрена весьма мелкая гранулярность необязательных возможностей (всего их сорок). С другой стороны, проведено объединение взаимосвязанных необязательных возможностей в группы, что во многих случаях избавляет от анализа большого числа опций. Группы эти таковы:

шифрование ;

средства реального времени;

продвинутые средства реального времени;

потоки реального времени;

продвинутые потоки реального времени;

трассировка ;

ПОТОКИ;

унаследованные возможности.

Например, в группу "средства реального времени" (_XOPEN_REALTIME) входят возможности четырнадцати видов, в том числе планирование на основе приоритетов, асинхронный ввод/вывод, семафоры, таймеры и т.п. Версия ОС Linux, на которой готовился текст данного курса, выдавала следующие значения некоторых конфигурационных констант (см. листинг 1.1).

$ getconf _POSIX_VERSION 199506 $ getconf POSIX2_C_DEV 1 $ getconf _XOPEN_REALTIME 1 $ getconf _POSIX_TRACE undefined Листинг 1.1. Результат применения утилиты getconf к одной из версий ОС Linux.

Это значит, что поддерживается устаревшая версия стандарта POSIX, среди прочих присутствуют средства разработки и возможности реального времени; средства трассировки отсутствуют. В документации на ОС должны быть отражены вопросы соответствия стандарту POSIX, описаны поддерживаемые дополнительные и нестандартные возможности. Для приложений понятие соответствия стандарту POSIX богаче нюансами. Предусмотрено строгое соответствие , главный отличительный признак которого - ограничение круга используемых возможностей рамками стандарта. Рассматривается и соответствие с применением расширений; в этом случае документация на приложение должна содержать описание требуемых нестандартных возможностей. Желательно, чтобы используемые расширения POSIX-возможностей описывались международными и/или национальными стандартами. (Отметим, что для реализации понятие строгого POSIX-соответствия бессмысленно хотя бы по той причине, что не бывает операционных систем без средств администрирования, а они не описываются данным стандартом.) Профилем будем называть набор опций, описывающих необязательные возможности. Соответствие профилю означает соответствие стандарту POSIX и поддержку заданных возможностей. Разумным образом выбранные профили позволяют учитывать потребности представительных классов пользователей и/или приложений. Допускается существование "подпрофилей ", описывающих подмножества стандартных возможностей. Реализация, соответствующая подпрофилю, может функционировать на аппаратных платформах с ограниченными ресурсами и/или обслуживать нужды специфических приложений. К числу важнейших принадлежат понятия, описывающие поведение реализации в различных ситуациях. Для многих корректных ситуаций поведение бывает неспецифицированным, а значит, мобильное приложение не должно полагаться на совпадение поведения разных реализаций. Для некорректных ситуаций поведение может быть неопределенным; приложению не только не следует полагаться на определенный характер подобного поведения - оно не должно совершать некорректных действий, вызывающих неопределенное поведение . Еще один близкий термин, "поведение, зависящее от реализации ", дополнительно означает, что поведение реализации необходимо документировать. Стандарт POSIX - это существующий много лет, развивающийся организм, в котором с каждой новой редакцией что-то появляется, а что-то утрачивается. Устаревшими называются возможности, которые еще поддерживаются различными реализациями, но в будущем они, вероятно, отомрут. Новые приложения не должны их использовать; для каждой из них стандартом предусмотрена адекватная по функциональности современная замена. Более ограниченный смысл придан термину "унаследованный ": он описывает устаревшие необязательные возможности, которых, разумеется, следует избегать в новых приложениях.

Основные понятия операционных систем, соответствующих стандарту POSIX

Мы рассмотрим следующие основные понятия операционных систем, соответствующих стандарту POSIX:

пользователь ;

файл ;

процесс ;

терминал ;

хост ;

узел сети ;

время ;

языково-культурная среда .

Это первичные понятия. Их нельзя строго определить, но можно пояснить с помощью других понятий и отношений. Для каждого из выделенных понятий будут описаны присущие им атрибуты и применимые к ним операции. В тексте стандарта POSIX содержатся следующие пояснения основных понятий вместе со ссылками на атрибуты и операции.

У пользователя есть имя и числовой идентификатор.

Файл - объект, допускающий чтение и/или запись и имеющий такие атрибуты, как права доступа и тип. К числу последних относятся обычный файл, символьный и блочный специальные файлы, канал, символьная ссылка, сокет и каталог. Реализация может поддерживать и другие типы файлов.

Процесс - адресное пространство вместе с выполняемыми в нем потоками управления, а также системными ресурсами, которые этим потокам требуются.

Терминал (или терминальное устройство) - символьный специальный файл, подчиняющийся спецификациям общего терминального интерфейса.

Сеть - совокупность взаимосвязанных хостов.

Языково-культурная среда - часть пользовательского окружения, зависящая от языковых и культурных соглашений.

Для работы с большим числом сущностей всегда предоставляются механизмы группирования и построения иерархий. Существует иерархия файлов, группы пользователей и процессов, подсети и т.п. Для написания программ, оперирующих с сущностями POSIX-совместимых систем, применяются командный интерпретатор (язык shell ) и/или компилируемый язык C. В первом случае приложение может пользоваться служебными программами (утилитами), во втором - функциями. Функциональный интерфейс операционных систем естественно считать первичным, поскольку большинство служебных программ предназначены, по сути, для вызова той или иной функции. По этой причине далее мы будем рассматривать преимущественно уровень функций. Основными операциями, применимыми к объектам ОС, являются чтение, запись и выполнение. Механизм прав доступа позволяет избирательно разрешать и запрещать осуществление подобных операций. Ранее в стандарте фигурировало понятие суперпользователя, не подверженного контролю прав доступа. В POSIX-2001 выбрана более гибкая формулировка - "имеющий соответствующие привилегии ", что отражает прогресс в реализации ОС с расщеплением суперпользовательских возможностей. В POSIX-совместимых ОС определены объекты, которые можно назвать вспомогательными; они помогают организовать взаимодействие между основными сущностями. Особенно широк спектр средств межпроцессного взаимодействия . Процессы выполняются в определенном окружении, частью которого является языково-культурная среда (Locale), образованная такими категориями, как символы и их свойства, форматы сообщений, дата и время, числовые и денежные величины. Как правило, с процессом ассоциированы по крайней мере три файла - стандартный ввод , стандартный вывод , стандартный протокол . Обычно стандартный ввод назначается на клавиатуру терминала, а стандартный вывод и стандартный протокол - на экран. Со стандартного ввода читаются команды и (иногда) исходные данные для них. На стандартный вывод поступают результаты выполнения команд. В стандартный протокол помещаются диагностические сообщения. К операционным системам могут предъявляться качественные требования, например, требование поддержки реального времени: способность обеспечить необходимый сервис в течение заданного отрезка времени.

Среда компиляции POSIX-совместимых приложений

Как правило (хотя это и не всегда осознается), разработка приложений ведется в кросс-режиме, то есть платформа разработки (эквивалентный термин - инструментальная платформа ) не совпадает с платформой выполнения (называемой также целевой платформой ). На инструментальной платформе создается среда компиляции приложений , так что результат компиляции может быть перенесен для последующего выполнения на целевую платформу. Важнейшая часть среды компиляции - заголовочные (или включаемые) файлы, содержащие прототипы функций , определения символических констант , макросов , типов данных, структур и т.п. Для каждой описанной в стандарте POSIX функции определено, какие заголовочные файлы должны быть включены использующим ее приложением (обычно требуется один файл). Выше было указано, что посредством символических констант, определенных в заголовочном файле , операционная система предоставляет приложению информацию о поддерживаемых возможностях. Стандартом POSIX предусмотрен симметричный механизм, называемый механизмом макросов проверки возможностей , он позволяет приложениям объявлять о своем желании получить доступ к определенным прототипам и именам. Основным макросом проверки возможностей является _POSIX_C_SOURCE . Среди требований к приложениям, строго соответствующим стандарту POSIX, фигурирует необходимость определения символической константы _POSIX_C_SOURCE со значением 200112L до включения каких-либо заголовочных файлов. Таким образом POSIX-совместимое приложение заявляет, что ему нужны POSIX-имена. Близкую по смыслу роль играет макрос _XOPEN_SOURCE (со значением 600 ). Примером использования макроса _POSIX_C_SOURCE во включаемых файлах ОС Linux может служить фрагмент, приведенный на листинге 1.2.

#if defined(_REENTRANT) || (_POSIX_C_SOURCE - 0 >= 199506L) #define LIBXML_THREAD_ENABLED#endif Листинг 1.2. Пример использования макроса проверки возможностей _POSIX_C_SOURCE.

Стандартом POSIX предусмотрены некоторые меры для решения важной и трудной проблемы (вызванной в первую очередь необъектным характером языка C), заключающейся в отсутствии пересечений по именам между приложением и операционной системой. Префиксы posix_ , POSIX_ и _POSIX_ зарезервированы для нужд стандарта. С подчеркивания, за которым следует еще одно подчеркивание или заглавная латинская буква, могут начинаться только системные (но не прикладные) имена. Для включаемых файлов описаны префиксы используемых в них имен. Например, для операций управления файлами, фигурирующих в , в качестве префиксов задействованы F_ , O_ , S_ . У средств межпроцессного взаимодействия, описанных в файле , префиксом служит IPC_ . К сожалению, заголовочных файлов много, а какая-то общая дисциплина именования отсутствует вследствие исторических причин. Так, для манипулирования характеристиками терминалов в файле определено множество разнообразных имен: EXTB , VDSUSP , DEFECHO , FLUSHO и т.п. Еще имеется четыреста семнадцать имен типа _Exit , abort , abs , acos и т.д., которые могут участвовать в редактировании внешних связей прикладной программы. В результате, прикладной программист может случайно "перебить" системный макрос, внешнюю переменную или функцию, поэтому целесообразно задействовать все диагностические средства среды компиляции и тщательно изучать выдаваемые ими сообщения.

Мобильность POSIX-совместимых приложений

Мобильность приложений, соответствующих стандарту POSIX, принципиально достижима благодаря двум основным факторам. Во-первых - это наличие огромного числа стандартизованных системных сервисов, а во-вторых - возможность динамического выяснения характеристик целевой платформы и подстройки под них приложения. (Естественно, мы имеем в виду мобильность в рамках, регламентируемых стандартом.) Приложения, соответствующие стандарту POSIX, могут быть одно- и многопроцессными, с возможностью динамической адаптации конфигурации к свойствам целевой платформы. Стандартизованы средства порождения и завершения процессов , смены их программ , опроса и/или изменения разнообразных характеристик. Процессы можно приостанавливать и активизировать в заданное время. Механизм сигналов позволяет извещать о событиях и завершать процессы внешним образом. Для их группирования предусмотрены средства управления заданиями . Приложения снабжены регуляторами для управления планированием и приоритетами процессов . Широк спектр средств межпроцессного взаимодействия (очереди сообщений , разделяемая память , семафоры ) и управления памятью . Наконец, в пределах процесса можно организовать несколько потоков управления. Необходимая степень детерминизма выполнения достигается благодаря средствам поддержки реального времени (к ним относятся управление дисциплиной выделение процессоров, сигналы реального времени, удержание страниц в оперативной памяти, таймеры высокого разрешения и т.д.). Функции для работы с файлами удовлетворяют потребности приложений в чтении и записи долговременных данных, защите таких данных от несанкционированного доступа. Механизм блокировки фрагментов файлов позволяет обеспечить атомарность транзакций. Асинхронный ввод/вывод дает возможность совмещать операции обмена, оптимизируя тем самым приложения. С помощью множества служебных программ можно относительно легко организовать сложную обработку данных. В стандарте POSIX тщательно проработаны вопросы доступа к внешним устройствам , подсоединенным по последовательным линиям, особенно к терминалам. Возможно, в большей детализации нуждаются средства работы с такими распространенными носителями, как магнитная лента. Стандартизованный командный язык shell - адекватное средство для написания небольших мобильных процедур и их быстрой интерактивной отладки. Выделим механизм конвейеров , позволяющий объединять команды в цепочки с фильтрацией промежуточных результатов. Служебные программы образуют развитую среду выполнения для shell-процедур. За счет фонового режима можно организовать одновременное выполнение нескольких программ и взаимодействие с ними посредством обычного терминала без многооконных возможностей (впрочем, окна, несомненно, не помешали бы). POSIX стандартизует интерфейс командной строки . В принципе, он достаточен, в меру удобен и, что важно, создает минимум проблем с точки зрения мобильности. Вероятно, в будущих версиях стандарта будет регламентирован графический интерфейс, но, безусловно, это чревато дополнительными сложностями для разработчиков мобильных приложений. Языково-культурная среда - одно из важнейших понятий стандарта POSIX с точки зрения мобильности. Приложения способны определять нужную им среду и адаптироваться к потребностям пользователей. Для многопользовательских систем требуется организация взаимодействия большого числа людей. POSIX решает эту проблему, регламентируя средства непосредственного и почтового обмена информацией. Стандартом POSIX предусмотрены базовые средства поддержки разработки (в первую очередь - для языка C), что, конечно, не снижает потребности в специализированных, развитых системах, когда речь идет о работе с действительно большими программными проектами. Приложениям предоставляются стандартизованные средства для выяснения как "крупноблочных" характеристик целевой системы (например, спектр поддерживаемых необязательных возможностей), так и более мелких характеристик (текущий размер свободного дискового пространства). Проблема мобильности приложений чрезвычайно сложна, и было бы преувеличением утверждать, что стандарт POSIX-2001 решает ее полностью. Во-первых, за его рамками остаются такие важнейшие вопросы, как графика, многооконный интерфейс и целый ряд других. Во-вторых, в регламентируемых областях присутствуют "белые пятна" неспецифицированного поведения реализаций. Тем не менее, подчеркнем это еще раз, следование стандарту POSIX - обязательный элемент современной дисциплины разработки прикладных систем.