Сегодня мы попытаемся выяснить, что описывает стандарт 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 является то, что он определяет "стандартизованный программный интерфейс", которого должны придерживаться разработчики сложных программно-аппаратных систем. Создатели этих систем вынуждены сталкиваться с такими требованиями, как сжатые сроки выхода на рынок (из-за жесткой конкуренции), минимизация затрат и ускорение возврата инвестиций. При этом львиная доля расходов, обусловленных замедлением процесса разработки, связана с тем, что программистам приходится "изобретать велосипед", снова и снова реализовывая функциональность, которая уже давно имеется. А ведь этого можно было бы избежать за счет:
Повторного использования кода из прошлых и параллельных проектов;
Переноса кода из других ОС;
Привлечения разработчиков из других проектов (в том числе с использованием других ОС).
Все это возможно благодаря применению ОС со стандартизованным 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 и (см. , что для нас важнее всего, международным стандартом 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 году, по завершении подготовительной работы, стандарт содержал следующие четыре части:$ 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 - это существующий много лет, развивающийся организм, в котором с каждой новой редакцией что-то появляется, а что-то утрачивается. Устаревшими называются возможности, которые еще поддерживаются различными реализациями, но в будущем они, вероятно, отомрут. Новые приложения не должны их использовать; для каждой из них стандартом предусмотрена адекватная по функциональности современная замена. Более ограниченный смысл придан термину "унаследованный ": он описывает устаревшие необязательные возможности, которых, разумеется, следует избегать в новых приложениях.
#if defined(_REENTRANT) || (_POSIX_C_SOURCE - 0 >= 199506L) #define LIBXML_THREAD_ENABLED#endif Листинг 1.2. Пример использования макроса проверки возможностей _POSIX_C_SOURCE.
Стандартом POSIX предусмотрены некоторые меры для решения важной и трудной проблемы (вызванной в первую очередь необъектным характером языка C), заключающейся в отсутствии пересечений по именам между приложением и операционной системой. Префиксы posix_
, POSIX_
и _POSIX_
зарезервированы для нужд стандарта.
С подчеркивания, за которым следует еще одно подчеркивание или заглавная латинская буква, могут начинаться только системные (но не прикладные) имена. Для включаемых файлов описаны префиксы
используемых в них имен. Например, для операций управления файлами, фигурирующих в
Алексей Федорчук
2005 г
Одной из отличительных особенностей логического устройства файловой системы операционок POSIX-семейства является их иерархическая, или древовидная, организации (правда, как я уже говорил дерево выглядит это немного странно). То есть здесь нет, как в DOS или Windows любого рода, обозначений (например, буквенных, или каких-либо иных) для отдельных носителей и их разделов: все они включаются в единую структуру в качестве подкаталогов главного каталога. называемого корневым. Процесс подключения файловых систем на самостоятельных физических носителях (и их разделах) к корню файлового древа называется монтированием, а подкаталоги, содержимое которых они составляют, именуются точками монтирования.
Исторически в Unix сложилась определенная структура каталогов, весьма сходная в разных представителях этого семейства в общих чертах, но несколько различающаяся в деталях. В частности, файловая иерархия в BSD-системах почти идентична, отличаясь от таковой в Linux. А в последней существенные отличия обнаруживаются между разными дистрибутивами. Вплоть до того, что структура файловой иерархии является одним из дистрибутив-специфичных признаков.
Такое положение дел затрудняет сочинение кросс-платформенных приложений. И потому существует и активно развивается проект стандартизации файловой иерархии — FHS (Filesystem Hierarchy Standard).
Проект FHS был направлен первоначально на упорядочивание структуры каталогов в многочисленных дистрибутивах Linux. Позднее он был приспособлен для других Unix-подобных систем (в том числе и BSD-клана). И ныне предпринимаются активные (но не очень успешные) усилия к тому, чтобы сделать его стандартом для POSIX-систем не только по имени, но и фактически.
Стандарт FHS покоится на двух основополагающих принципах — четком отделении в файловой иерархии каталогов разделяемых и неразделяемых, с одной стороны, и неизменяемых и изменяемых — с другой.
Противопоставление разделяемых и неразделяемых каталогов обусловлено изначально сетевой природой Unix. То есть данные, относящиеся к локальной машине (например, файлы конфигурирования ее устройств) должны лежать в каталогах, отдельных от тех, содержимое которых доступны с других машин в сети, локальной или глобальной (примером чему являются не только пользовательские данные, но и программы).
Суть противопоставления неизменяемых и изменяемых каталогов легко пояснить на примере. Так, те же общие пользовательские программы по природе своей должны быть неизменяемыми (вернее, доступными для модификации только администратору системы, но не самому пользователю, применяющему их в своей работе). В то же время эти программы при своей работе генерируют не только файлы данных, скажем, тексты или изображения (изменяемая их природа ясна без комментариев), но всякого рода служебную информацию, типа log-файлов, временных файлов и тому подобного). Каковая и должна группироваться в каталогах, отделенных от собственно исполнимых файлов программ, необходимых для их запуска библиотек, конфигурационных файлов и т.д.
Тем не менее, не смотря на активное продвижение во многих дистрибутивах Linux из числа наиболее распространенных, статуса истинного стандарта FHS не обрел. Существует немало дистрибутивов Linux, не использующие некоторые его положения. А с традиционной файловой иерархией BSD-систем он соотносится лишь частично.
И причина — в том, что FHS игнорирует еще одно противопоставление, очень важное для пользователя: противопоставление легко восстановимых частей файловой системы, и тех ее компонентов, которые восстановимы с трудом или невосстановимы вообще.
К первым, как ни странно, можно отнести саму базовую систему: ведь переустановка ее с дистрибутивного носителя, в случае фатального краха, дело не столь уж сложное. К трудновосстановимым частям файловой системы, очевидно, относятся пользовательские данные: даже в случае регулярного их резервирования (а многие ли пользователи столь аккуратны?) развертывание их из архивов потребует немалого времени (и почти неизбежно повлечет некоторые потери).
Кроме того, в BSD-системах и Source Based дистрибутивах Linux к трудновосстановимым каталогам я отнес бы все, связанное с пакетным менеджментом — дерево портов FreeBSD или pkgsrc в NetBSD (и системах, его заимствовавших), их аналоги в дистрибутивах Linux, собственно исходники портированных программ, да и исходные тексты системы тоже. Ибо, даже если все это имеется на дистрибутиве, эти компоненты файловой системы, как правило, поддерживаются пользователем в актуальном состоянии путем синхронизации по Сети с серверами проекта (иначе их использование лишено смысла). И их утрата повлечет как временные (особенно при модемном подключении), так и финансовые (мало кто является счастливым обладателем бесплатного доступа в Интернет) потери.
Четкое следовании концепции отчленения разделяемых и неразделяемых, неизменяемых и неизменяемых, восстановимых и невосстановимых каталогов друг от друга позволяет, в рамках единой древовидной файловой иерархии, обособить отдельные ее ветви физически — то есть в виде самостоятельных файловых систем, размещенных на изолированных устройствах (дисках, дисковых разделах, слайсах, партициях etc.). Резонов к тому много — и повышение быстродействия, и увеличение надежности, и просто соображения удобства, — но и о них сейчас речь не пойдет. Потому что в данный момент для нас важно только то, что эти ветви файлового древа должны быть инкорпорированы в общую файловую систему.
Собственно говоря, для функционирования абсолютно необходимо наличие лишь одной файловой системы — той, что монтируется в корневой каталог файлового древа (своего рода аналог мирового дерева Иггдрассиль). Корневой каталог и его непременные ветви обязательно должны составлять единую файловую систему, расположенную на одном носителе — диске, дисковом разделе, программном либо аппаратном RAID-массиве, или логическом томе в понимании LVM. И в нем должны располагаться все компоненты, необходимые для старта системы и, в идеале, — ничего сверх того.
Просмотреть состав корневого каталога можно командой
$ ls -1 /
которая в любой POSIX-системе покажет некий минимальный джентльменский набор каталогов:
Bin/ boot/ etc/ root/ sbin/
Именно в них собраны все файлы, без которых система не может существовать. Прочие каталоги — примерно такие:
Home/ mnt/ opt/ tmp/ usr/ var/
Они а) не обязательны (по крайней мере, теоретически — практически обойтись без них трудновато), б) не каждый из них присутствует во всех системах и дистрибутивах, и в) каждый из них может быть (и часто является — если все делать по уму) точкой монтирования собственной ветви файлового древа.
Кроме этого, в большинстве случаев в корне файловой системы POSIX-совместимых ОС присутствуют еще два подкаталога:
Dev/ proc/
Это обычно — точки монтирования виртуальных файловых систем — устройств и процессов, соответственно (хотя, если файловая система устройств не используется, каталог /dev обязательно должен быть компонентом корневой файловой системы. Наконец, в Linux-системах, как правило, в корне файлового древа лежит еще и каталог /lib , предназначенный для главных системных библиотек. А при использовании механизма udev неизбежным оказывается еще и каталог /sys , в который монтируется виртуальная файловая система sysfs .
Корневая файловая система является неразделяемой (то есть не предназначенной для совместного использования разными машинами сети) и неизменяемой (то есть изменения в нее может вносить только администратор системы, но не пользовательские программы и, тем более, не пользователи). Причем крайне не рекомендуется создавать в ней подкаталоги сверх предусмотренных стандартом (и перечисленных выше).
Наполнение корневой файловой системы подбирается с таким рассчетом, чтобы машина могла стартовать и сохраняла бы минимальную функциональность даже при аварийной загрузке (или в однопользовательском режиме), когда все остальные файловые системы не монтируются (и, соответственно, такие ее ветки, как /usr или /var , могут оказаться недоступными.
В соответствие с этим старт машины обеспечивается файлами каталогов /boot и /etc . В первом размещаются ядро системы — исполнимый файл «особого назначения», — и все, что требуется для его загрузки: в Linux, например, это системная карта (файл /etc/System.map), а во FreeBSD — загружаемые модули ядра. Впрочем, подчас ядро размещается непосредственно в корне файловой системы, и тогда каталог /boot может отсутствовать вовсе, а под модули ядра может отводиться каталог /modules .
Каталог /etc предназначен для общесистемных конфигурационных файлов, определяющих условия ее загрузки. Содержимое его очень сильно зависит от системы (а в Linux — еще и от дистрибутива), и потому рассматривать его здесь я не буду — к этой теме придется еще не раз возвращаться.
Минимально необходимая функциональность обеспечивается содержимым каталогов /bin и /sbin — в них собраны исполнимые файлы важнейших пользовательских и системных программ, соответственно, тех самых, которые позволят выполнить комплекс ремонтно-спасательных мероприятий и привести машину в человеческий вид после сбоя.
Разнесение системных и пользовательских программ по подкаталогам корня — достаточно условно. Ни одна из команд этих для решения пользовательских задач по настоящему не предназначена. Просто в каталоге /bin собраны команды администрирования, к которым время от времени обращается (или может обратиться) и обычный пользователь, а каталог sbin предназначен для команд, о которых пользователю и знать-то не положено. И которыми он, в большинстве случаев, все равно не сможет воспользоваться по причине отсутствия соответствующих полномочий (например, требуемых прав доступа к файлам устройств).
Для запуска POSIX-программ (в том числе и тех, что собраны в каталогах /bin и sbin), как правило, требуется доступ к функциям общесистемных библиотек (в первую очередь — главной библиотеки glibc). И потому (почти) непременный компонент корневого каталога — подкаталог /lib , в коем они и собраны.
В Linux каталог /lib служит еще одной важной цели — в его подкаталоге (/lib/modules) собраны загружаемые модули ядра (во FreeBSD их место — каталог /boot/kernel).
Во FreeBSD каталога /lib в корневой файловой системе не обнаруживается — соответствующие компоненты здесь размещаются в /usr/lib (см. далее). Это связано с тем, что исторически во FreeBSD важнейшие общесистемные программы собирались так, что требуемые им библиотечные функции встраивались в их исполнимые файлы (так называемая статическая линковка, о которой речь пойдет в главе 14). Во FreeBSD 5-й ветки программы из каталогов /bin и /sbin линкуются динамически, то есть при отсутствии каталога /usr (а во Free это почти всегда отдельная ветвь файловой системы) они не функционируют. В компенсацию чего предусмотрен выходящий за рамки стандартов каталог /restore , содержащий те же программы, но слинкованные статически (как следует из имени каталога, единственным назначением его содержимого являются аварийно-спасательные работы).
И, наконец, /root . Это — обычный домашний каталог одноименного пользователя, сиречь администратора системы. Поскольку никакой практической работы он не делает (или, по крайней мере, делать не должен), содержимое его — лишь собственные конфигурационные файлы суперпользователя (пользовательской командной оболочки, любимого редактора и так далее).
Исторически каталог /usr предназначался для пользовательских программ и данных. Ныне эти функции распределены между каталогами /usr/local и /home (хотя и сейчас во FreeBSD по умолчанию последний представляет собой символическую ссылку на /usr/home). Каталог же /usr — не изменяемый, но разделяемый, — служит вместилищем основной части прикладных программ и всего, что к ним относится — исходных текстов, конфигурационных файлов, разделяемых библиотек, документации и тому подобного хозяйства.
Состав каталога /usr существенно различается в BSD-системах и в Linux. В первых в него помещаются только неотъемлемые части операционной системы (того, что во FreeBSD объединяется понятием Distributions). Приложения же, устанавливаемые из портов или пакетов, имеют место своей прописки подкаталог /usr/local , который может представлять отдельную ветвь файлового древа.
В Linux каталог /usr служит вместилищем всех программ (и их компонентов), штатно включенных в состав дистрибутива. А подкаталог /usr/local предназначается обычно для программ, самостоятельно собираемых из исходников.
В любом случае, обычный состав каталога /usr следующий (по выводу команды ls -1):
X11R6/ bin/ etc/ include/ lib/ libexec/ local/ sbin/ share/ src/
Как уже говорилось, подкаталог /usr/local — отдельная ветвь файлового древа, и потому будет рассмотрен отдельно же. Назначение же прочих каталогов таково:
Кроме этого, в каталоге /usr могут обнаружиться подкаталоги /usr/var и /usr/tmp — обычно символические ссылки на соответствующие ветви корневого каталога. А в некоторых дистрибутивах Linux непосредственно в /usr помещается и основная общесистемная документация — man-страницы (в подкаталог /usr/man).
Наконец, в BSD-системах и некоторых Source Based дистрибутивах Linux (например, Gentoo) в каталоге /usr размещается подкаталог для системы управления пакетами — портов FreeBSD и OpenBSD (/usr/ports), их аналогов в других системах (/usr/portage в Gentoo). Хотя с точки зрения следования букве и духу стандарта FHS (сам он о портах и подобных системах не упоминает ни словом), более логичным местом их размещения был бы каталог /var (см. ниже) — и именно так делается в таких дистрибутивах, как CRUX и Archlinux.
Как уже было сказано, ветвь /usr/local в Linux предназначена для самостоятельно собираемых из исходников (не входящих в данный дистрибутив) программ. А во FreeBSD она служит вместилищем большей части пользовательских приложений — почти всего того, что выходит за рамки Distributions и устанавливается из пакетов или портов. Соответственно этому, структура каталога в целом повторяет таковую ветви /usr (с понятными исключениями):
Bin/ etc/ include/ lib/ man/ sbin/ share/
Содержимое подкаталогов также аналогично: исполнимые файлы программ (/usr/local/bin и /usr/local/sbin), их конфиги (/usr/local/etc), библиотеки, с которым они связаны, и их заголовочные файлы (/usr/local/lib и /usr/local/include , соответственно), man-страницы (/usr/local/man) и всякая архитектурно независимая всячина (/usr/local/share), в том числе и документация в иных форматах.
Каталог /opt предусмотрен стандартом FHS, но реально используется не во всех дистрибутивах Linux, а в BSD-системах и вовсе отсутствует. Тем не менее, все больше программ пишется в рассчете на умолчальную инсталляцию именно в него.
Исторически каталог /opt предназначался в Linux для коммерческих приложений и всякого рода программ не вполне свободного характера. Ныне же его назначение — размещение больших самодостаточных программных комплексов, таких, как библиотека Qt, KDE со всеми его компонентами и приложениями, OpenOffice.org и тому подобных. Структура каталога должна быть такой: /opt/pkg_name . Вот как выглядит она а в моей системе (Archlinux):
$ ls -1 /opt gnome/ kde/ OpenOffice.org1.1.2/ qt/
Каждый из подкаталогов имеет собственную внутреннюю структуру:
$ ls -1 /opt/* /opt/gnome: bin/ lib/ man/ share/ /opt/kde: bin/ etc/ include/ lib/ share/ /opt/OpenOffice.org1.1.2: help/ LICENSE LICENSE.html program/ README README.html setup@ share/ spadmin@ THIRDPARTYLICENSEREADME.html user/ /opt/qt: bin/ doc/ include/ lib/ mkspecs/ phrasebooks/ plugins/ templates/ translations/
Назначение подкаталогов внутри /opt/pkg_name легко угадывается по аналогии с /usr и /usr/local . Например /opt/kde/bin предназначается для исполнимых файлов системы KDE и ее приложений, /opt/kde/etc — для конфигурационных ее файлов, /opt/kde/include — для файлов заголовков, /opt/kde/lib — для библиотек и /opt/kde/share — для разделяемых файлов, в том числе и документации. В KDE нет документации в man-формате, если же она имеется, то (как в случае Gnome — я его не ставил, это то, что потянули Gimp и тому подобные Gtk-приложения) можно видеть подкаталог /opt/pkg_name/man .
Можно видеть, что структура каталога /opt отступает от исторически сложившейся (и внутренне обоснованной POSIX-традиции объединения в каталоги однотипных компонентов — исполняемых файлов, библиотек и так далее. И при большом количестве инсталлированных в него программ создает определенные трудности: приходится либо перегружать значениями переменную $PATH , обеспечивающую быстрый доступ к командам (о чем будет говориться в главе 12), либо создавать специальный каталог /opt/bin и помещать в него символические ссылки на исполняемые бинарники программ. Поэтому в ряде дистрибутивов Linux (например, в CRUX) каталог /opt не используется принципиально. Как, впрочем, и во всех BSD-системах. Вполне возможно, что так оно и лучше…
Как явствует из названия, каталог /var предназначен для хранения изменяемых файлов, генерируемых в ходе нормальной жизнедеятельности различных программ — программных (например, браузерных) кэшей, log-файлов, спулинга печати и почтовых систем, почтовых ящиков, описаний запущенных процессов и так далее. В частности, именно в каталог /var помещаются так называемые дампы — слепки состояния оперативной памяти, генерируемые при аварийном завершении работы для выявления причин оного. Отличительная особенность всех этих компонентов — их изменчивый в процессе сеанса работы характер и то, что они, тем не менее, должны сохраняться при перезагрузке системы.
Внутренняя структура /var очень сильно меняется от системы к системе, и поэтому на деталях ее устройства я задерживаться не буду. Замечу только, что этот каталог — логичное место для помещения компонентов всякого рода портообразных систем управления пакетами, как это сделано, например, в дистрибутиве Archlinux, где под нее отведен подкаталог /var/abs (abs — Archlinux Building System).
Каталог /mnt предназначен для монтирования временно используемых файловых систем, располагающихся, как правило, на сменных носителях. В всежеустановленной системе он обычно пуст, и структура его никак не регламентирована. Пользователю вольно создать в нем подкаталоги для отдельных видов носителей. Например, в моей системе это /mnt/cd , /mnt/dvd , /mnt/usb и /mnt/hd — для дисков CD, DVD, флэшки и съемного винчестера.
Во FreeBSD штатными каталогами для монтирования CD и дискет являются /cdrom и /floppy непосредственно в корневом каталоге. Что не вполне согласуется со стандартом, но по своему логично — в корень вынесены точки монтирования устройств, существующих (как CD ROM) или до недавнего времени существовавших (флоппи-дисковод) в любой машине.
Каталог /home предназначен для помещения домашних каталогов пользователей. Содержимое его никак не регламентировано, но обычно он имеет вид вроде /home/{username1,...,username#} . Хотя в крупных системах с большим количеством пользователей их домашние каталоги могут быть объединены в группы.
В каталоге /home могут располагаться домашние каталоги не только реальных, но и некоторых виртуальных пользователей. Так, если машина используется в качестве web- или ftp-сервера, можно видеть такие подкаталоги, как /home/www или /home/ftp , соответственно.
Осталось поговорить только о каталоге для хранения временных файлов — /tmp . Как и компоненты /var , они генерируются различными программами в ходе нормальной их жизнедеятельности. Но, в отличие от /var , для компонентов /tmp не предполагается их сохранения вне текущего сеанса работы. Более того, все руководства по системному администрированию рекомендуют регулярно (например, при рестарте машины) или периодически очищать этот каталог. И потому в качестве /tmp целесообразно монтировать файловые системы в оперативной памяти — tmpfs (в Linux) или mfs (во FreeBSD). Кроме того, что это гарантирует очистку его содержимого при перезагрузке, так еще и способствует быстродействию, например, компиляции программ, временные продукты которой не записываются на диск, а помещаются в виртуальный каталог типа /tmp/obj .
Во многих системах можно увидеть каталоги вроде /usr/tmp и /var/tmp . Это, как правило, символические ссылки на /tmp .
В заключение разговора о файловой иерархии следует подчеркнуть, что гарантированно на одной файловой системе (фигурально говоря, на одном дисковом разделе, хотя это и не совсем точно) должны находиться только каталоги, перечисленные в параграфе Корневая файловая система . Все же прочие каталоги — /usr , /opt , /var , /tmp и, конечно же, /home могут представлять точки монтирования самостоятельных файловых систем на отдельных физических носителях или их разделах.
Более того, в локальной сети каталоги эти вполне могут располагаться даже на разных машинах. Так, один компьютер, выполняющий роль сервера приложений, может содержать разделяемые в сети каталоги /usr и /opt , другой — файл-сервер, — вмещать все домашние каталоги пользователей, и так далее.
Осталось только решить — какие файловые системы целесообразно вычленить из общего файлового древа, и зачем это делать. Ответ на эти вопросы очень сильно зависит от используемой ОС, а в случае с Linux — еще и от его дистрибутива. Тем не менее, общие принципы отделения файловых систем наметить можно. Для чего следует вспомнить о противопоставлении, с одной стороны, неизменяемых и изменяемых каталогов, с другой — легко восстановимых, трудно восстановимых и практически невосстановимых данных. Проделаем такую попытку применительно к пользовательскому десктопу — в случае сервера рассчеты будут существенно иными.
Очевидно, что корневая файловая система в составе каталогов /bin , /boot , /etc , /root , /sbin , содержащих легко восстановимые с дистрибутивного носителя и практически не изменяемые данные, должны лежать на изолированном дисковом разделе. В Linux к ним должен добавиться еще и каталог /lib . С другой стороны, при использовании в качестве загрузчика GRUB (вне зависимости от операционной системы) рекомендуется вынести на отдельный раздел каталог /boot .
В старых источниках о Linux можно прочитать о другом резоне к выделению раздела для каталога /boot , причем в самом начале диска: из-за невозможности загрузки ядра программой Lilo с цилиндра номером выше, чем 1023. В современных версиях загрузчиков таких ограничений нет. Тем не менее, если уж раздел под /boot создается, резонно сделать его первым на диске, а непосредственно за ним разместить раздел подкачки: это добавит пять копеек быстродействия при осуществлении своппинга.
И еще из области истории: требование, чтобы корневой и загрузочный разделы были непременно первичными, также давно снято. И эти файловые системы вполне могут помещаться на логических разделах внутри Extended Partition.
Столь же ясно, что изменяемые ветви файловой системы — каталоги /var и /tmp , — должны быть вынесены за пределы корневого раздела. Причем последний, как неоднократно говорилось ранее, вообще целесообразно разместить на файловой системе в оперативной памяти (tmpfs или mfs). В случае, если каталог /var содержит подкаталоги для портообразных систем пакетного менеджмента, подобно /var/abs , /var/cache/pacman/src и /var/cache/pacman/pkg в Archlinux, они также должны образовывать самостоятельные файловые системы
Теперь — каталог /usr , содержащий либо компоненты базовой системы (как в BSD), либо — основную массу пользовательских приложений (как в большинстве дистрибутивов Linux). Он содержит легковосстановимые данны и, по хорошему, должен бы быть практически неизменяемым, и потому, безусловно, заслуживает выделения на самостоятельном разделе. Причем из его состава целесообразно вычленить, с одной стороны, подкаталоги /usr/X11R6 и /usr/local , с другой — подкаталоги для портообразных систем пакетного менеджмента: /usr/ports , /usr/pkgsrc и /usr/pkg в BSD-системах, /usr/portages в Gentoo Linux, и так далее. Причем от последних следует обособить подкаталоги для помещения исходников, скачиваемых из сети при сборке портов — /usr/ports/distfiles , /usr/pkgsrc/disfiles , /usr/portages/distfiles и подобные им.
В BSD-системах, кроме этого, из каталога /usr имеет смысл выделить подкаталоги /usr/src и /usr/obj , содержащие исходные тексты базовых компонентов (включая ядро) и промежуточные продукты их компиляции, образумемые в результате процедур make buildworld и make buildkernel .
И, наконец, каталог /home , содержащий изменяемые и часто невосстановимые данные, подлежит вынесению из корня файловой иерархии в обязательном порядке. Причем я всегда стараюсь разместить его либо на отдельном слайсе (в BSD), либо на первичном разделе (в Linux).
Предложенная схема разделения файловых систем может показаться излишне усложненной. Однако она дает гарантию обособления легко восстановимых, трудно восстановимых и невосстановимых данных, что облегчит переустановку системы в случае крайней необходимости, и даже миграцию с системы на систему.
Дополнительный ее плюс — в том, что для отдельных ветвей файлового древа, в зависимости от характера размещенных на ней данных, в Linux можно подобрать физически оптимальную файловую систему. Например, для раздела под /boot нет смысла использовать что-либо помимо Ext2fs. Корневой раздел обычно рекомендуется форматировать в надежной и при этом наиболее совместимой Ext3fs. Под каталоги с огромным количеством мелких файлов, такие, как /var/abs в Archlinux, /usr/portages в Gentoo, целесообразно задействовать ReiserFS: ведь умелое обращение с мелкими файлами — это ее профиль. А в каталоге /home , где возможно появление огромных мультимедийных файлов (и который сам по себе обычно очень велик), ко двору может прийтись XFS (хотя, как показывают измерения, и ReiserFS выглядит тут вполне достойно). Такие меры могут способствовать повышению и надежности хранения данных, и быстродействию файловых операций.
Пользователи BSD-операционок безальтернативно привязаны к файловым система типа FFS. Однако и у них есть пространство для маневра. Во-первых — за счет варьирования размеров блока и фрагмента отдельных файловых систем, способствующего либо производительности дисковых операций, либо экономии дискового пространства. А во-вторых, некоторые ветви файлового древа (такие, как /tmp или /usr/obj , вопреки рекомендациям, можно безбоязненно монтировать в чисто асинхронном режиме, выиграв на этом процент-другой производительности.
Сергей Золотарев, Николай Горбунов
Целью данной статьи является попытка внести определенную ясность в историю развития стандарта POSIX применительно к операционным системам реального времени (ОС РВ).
Одним из важнейших свойств стандарта POSIX является то, что он определяет "стандартизованный программный интерфейс", которого должны придерживаться разработчики сложных программно-аппаратных систем. Создатели этих систем вынуждены сталкиваться с такими требованиями, как сжатые сроки выхода на рынок (из-за жесткой конкуренции), минимизация затрат и ускорение возврата инвестиций. При этом львиная доля расходов, обусловленных замедлением процесса разработки, связана с тем, что программистам приходится "изобретать велосипед", снова и снова реализовывая функциональность, которая уже давно имеется. А ведь этого можно было бы избежать за счет:
Все это возможно благодаря применению ОС со стандартизованным API. Причем если в первом случае организации достаточно иметь некий внутренний стандарт (что особенно характерно для фирменных ОС), то вторые два случая как раз требуют наличия общепризнанных стандартов – например, 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 подкомитетов, курирующих все разработки – от программного обеспечения до языков программирования, компьютерной графики и редактирования изображений, взаимосвязи оборудования и методов безопасности.
Подготовка новых стандартов IEC включает несколько стадий (предварительная, стадия предложения, подготовительная, стадия технического комитета, стадия запроса, одобрения, публикации). Если запланировано, что документ IEC станет только технической спецификацией, а не международным стандартом, пересмотренная версия документа посылается в центральный офис для издания. На выработку заключительного проекта международного стандарта (FDIS) отводится четыре месяца. Если его одобрят все члены технического комитета, он направляется в центральный офис для публикации без стадии одобрения FDIS. После этого FDIS попадает в национальные комитеты, которые должны утвердить его в течение двух месяцев. FDIS считается одобренным, если за него проголосовало более двух третей национальных комитетов, а количество отрицательных голосов не превышает 25%. Если документ не одобрен, он отправляется для пересмотра в технические комитеты и подкомитеты. Стандарт должен быть опубликован не позднее чем через два месяца после одобрения FDIS.
К выработке и принятию стандартов 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 предложен Ричардом Столлманом (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 в рамках различных международных организаций.
Первая версия спецификации 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.
Для операционных систем реального времени наиболее важны семь спецификаций стандарта (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21 ), но широкую поддержку в коммерческих ОС получили только три:
Кроме указанных стандартов важными для ОС РВ являются следующие стандарты, которые были реализованы в рамках работы над проектом Std 1003.1-2001:
Чтобы соответствовать стандарту 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™ 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, если он прошел полную процедуру сертификации, по результатам тестирования удовлетворяет всем предъявленным требованиям и занесен в официальный реестр сертифицированных продуктов .
Наборы тестов включают:
Кроме того, Open Group разработала тесты для стандартов POSIX Realtime и профиля стандартов Embedded POSIX. Набор тестов для POSIX Realtime (www.opengroup.org/testing/testsuites/realtime.html) включает следующие тесты:
Набор тестов профиля стандартов Embedded POSIX (www.opengroup.org/testing/testsuites/embedded.html) включает следующие тесты:
Применительно к группе стандартов POSIX в английском языке часто используются не один, а целых три термина. К сожалению, они сходны по значению и часто переводятся одинаково, что вносит определенную путаницу. Термины эти таковы:
Первый термин применительно к 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.
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):
Компания QNX Software Systems, создатель QNX Neutrino, планирует также сертификацию (conformance) QNX Neutrino по некоторым из этих стандартов; работы запланированы на 2005 г. (www.qnx.com/news/pr_959_1.html).
Литература
