Алексей Федорчук
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.). Резонов к тому много — и повышение быстродействия, и увеличение надежности, и просто соображения удобства, — но и о них сейчас речь не пойдет. Потому что в данный момент для нас важно только то, что эти ветви файлового древа должны быть инкорпорированы в общую файловую систему.

Типовой набор каталогов POSIX-системы

Собственно говоря, для функционирования абсолютно необходимо наличие лишь одной файловой системы — той, что монтируется в корневой каталог файлового древа (своего рода аналог мирового дерева Иггдрассиль). Корневой каталог и его непременные ветви обязательно должны составлять единую файловую систему, расположенную на одном носителе — диске, дисковом разделе, программном либо аппаратном 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 предназначался для пользовательских программ и данных. Ныне эти функции распределены между каталогами /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/bin и /usr/sbin предназначены для исполнимых файлов пользовательских и системных программ (здесь граница между ними еще более условна, чем в случае корневого каталога), назначение которых выходит за рамки обеспечения базового функционирования системы;
• /usr/etc предназначается для конфигурационных файлов отдельных приложений;
• /usr/include содержит так называемые заголовочные файлы, необходимые для линковки исполняемых файлов с библиотечными компонентами;
• /usr/lib и /usr/libexec — каталоги для разделяемых библиотек, от которых зависят пользовательские приложения;
• /usr/share — вместилище самых разнообразных, т.н. архитектурно независимых, компонентов: здесь можно видеть и документацию в разных форматах, и примеры конфигурационных файлов, и данные, используемые программами управления консолью (шрифты, раскладки клавиатуры), и описание часовых поясов;
• /usr/src — каталог для исходных текстов; в Linux тут штатно помещаются только исходники ядра (ядер) системы, в BSD же клонах — полный набор исходников того комплекса, который во FreeBSD именуется Distributions; исходники самостоятельно собираемых программ помещать сюда, как правило, нежелательно;
• /usr/X11R6 — каталог для компонентов оконной системы Икс — исполнимых файлов (/usr/X11R6/bin), библиотек (/usr/X11R6/lib), заголовков (/usr/X11R6/include), документации (/usr/X11R6/man); файлы Иксовых приложений сюда помещаться не должны (за исключением, разве что, оконных менеджеров) — их место в /usr , /usr/local или /opt , в зависимости от системы.

Кроме этого, в каталоге /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

Как уже было сказано, ветвь /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

Каталог /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

Как явствует из названия, каталог /var предназначен для хранения изменяемых файлов, генерируемых в ходе нормальной жизнедеятельности различных программ — программных (например, браузерных) кэшей, log-файлов, спулинга печати и почтовых систем, почтовых ящиков, описаний запущенных процессов и так далее. В частности, именно в каталог /var помещаются так называемые дампы — слепки состояния оперативной памяти, генерируемые при аварийном завершении работы для выявления причин оного. Отличительная особенность всех этих компонентов — их изменчивый в процессе сеанса работы характер и то, что они, тем не менее, должны сохраняться при перезагрузке системы.

Внутренняя структура /var очень сильно меняется от системы к системе, и поэтому на деталях ее устройства я задерживаться не буду. Замечу только, что этот каталог — логичное место для помещения компонентов всякого рода портообразных систем управления пакетами, как это сделано, например, в дистрибутиве Archlinux, где под нее отведен подкаталог /var/abs (abs — Archlinux Building System).

Каталог /mnt

Каталог /mnt предназначен для монтирования временно используемых файловых систем, располагающихся, как правило, на сменных носителях. В всежеустановленной системе он обычно пуст, и структура его никак не регламентирована. Пользователю вольно создать в нем подкаталоги для отдельных видов носителей. Например, в моей системе это /mnt/cd , /mnt/dvd , /mnt/usb и /mnt/hd — для дисков CD, DVD, флэшки и съемного винчестера.

Во FreeBSD штатными каталогами для монтирования CD и дискет являются /cdrom и /floppy непосредственно в корневом каталоге. Что не вполне согласуется со стандартом, но по своему логично — в корень вынесены точки монтирования устройств, существующих (как CD ROM) или до недавнего времени существовавших (флоппи-дисковод) в любой машине.

Ветвь /home

Каталог /home предназначен для помещения домашних каталогов пользователей. Содержимое его никак не регламентировано, но обычно он имеет вид вроде /home/{username1,...,username#} . Хотя в крупных системах с большим количеством пользователей их домашние каталоги могут быть объединены в группы.

В каталоге /home могут располагаться домашние каталоги не только реальных, но и некоторых виртуальных пользователей. Так, если машина используется в качестве web- или ftp-сервера, можно видеть такие подкаталоги, как /home/www или /home/ftp , соответственно.

Ветвь /tmp

Осталось поговорить только о каталоге для хранения временных файлов — /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 (Portable Operating System Interface for Computer Environments - незави­симый от платформы системный интерфейс для компьютерного окружения) - это стандарт IEEE (Institute of Electrical and Electronics Engineers - институт инже­неров по электротехнике и радиоэлектронике), описывающий системные интер-

" В данном контексте под системными командами следует понимать некий набор программ, позволя­ющих управлять вычислительными процессами, например pstat, kill, dir и др.

Интерфейс POSIX___________________________________________________ 305

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

Интерфейс POSIX начинался как попытка пропаганды институтом IEEE идей переносимости приложений в UNIX-средах путем разработки абстрактного неза­висимого от платформы стандарта. Однако POSIX не ограничивается только UNIX-системами; существуют различные реализации этого стандарта в системах, которые соответствуют требованиям, предъявляемым стандартом IEEE Standard 1003.1-1990 (POSIX. 1). Например, известная ОС реального времени QNX соответствует спецификациям этого стандарта, что облегчает перенос приложений в эту систе­му, но UNIX-системой не является ни в каком виде, ибо ее архитектура использу­ет абсолютно иные принципы.

Этот стандарт подробно описывает систему виртуальной памяти (Virtual Memory System, VMS), многозадачность (Multiprocess Executing, МРЕ) и технологию пе­реноса операционных систем (CTOS). Таким образом, на самом деле POSIX пред­ставляет собой множество стандартов POSIX. 1-POSIX. 12. В табл. 9.1 перечисле­ны основные направления, описываемые данными стандартами. Следует также особо отметить, что в POSIX. 1 основным языком описания системных функций API предполагается язык С.

Таблица 9.1. Семейство стандартов POSIX

Стандарт Стандарт ISO Краткое описание

POSIX.0 Нет Введение в стандарт открытых систем. Данный документ

не является стандартом в чистом виде, а представляет собой рекомендации и краткий обзор технологий

POSIX.1 Да Системный интерфейс API (язык С)

POSIX.2 Нет Оболочки и утилиты (одобренные IEEE)

POSIX.3 Нет Тестирование и верификация

POSIX.4 Нет Задачи реального времени и потоки выполнения

POSIX.5 Да Использование языка ADA применительно

к стандарту POSIX. 1

POSIX.6 Нет Системная безопасность

POSIX.7 Нет Администрирование системы

POSIX.8 Нет Сети, «прозрачный» доступ к файлам, абстрактные

сетевые интерфейсы, не зависящие от физических протоколов, вызовы RPC, связь системы с приложениями, зависящими от протокола

POSIX.9 Да Использование языка Fortran, применительно

к стандарту POSIX. 1

POSIX. 10 Нет Super-computing Application Environment Profile (AEP)

POSIX. 11 Нет Обработка транзакций AEP

POSIX. 12 Нет Графический интерфейс пользователя (GUI)

306______________________________ Глава 9. Архитектура операционных систем

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

Рис. 9.1. Схема реализации приложения, строго соответствующего стандарту POSIX

Из рисунка видно, что для взаимодействия с операционной системой программа использует только библиотеки POSIX. 1 и стандартную библиотеку RTL языка С, в которой возможно использование только 110 различных функций, также опи­санных стандартом POSIX. 1.

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

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

Примеры программирования для разных интерфейсов API____________________ 307

Примеры программирования для разных интерфейсов API

Для наглядной демонстрации принципиальных различий интерфейсов API наи­более популярных современных операционных систем для персональных ком­пьютеров рассмотрим простейший пример, в котором необходимо подсчитать количество пробелов в текстовых файлах, имена которых должны указываться в ко­мандной строке. Рассмотрим два варианта программы: для Windows (с использо­ванием WinAPI) и для Linux (POSIX API).

Поскольку нас интересует работа с параллельными задачами, пусть при выполне­нии программы для каждого из перечисленных в командной строке файлов созда­ется свой процесс или поток выполнения (задача), который параллельно с други­ми процессами (потоками) производит работу по подсчету пробелов в «своем» файле. Результатом работы программы будет являться список файлов с подсчи­танным количеством пробелов для каждого.

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

Для того чтобы было удобнее сравнивать эту (листинг 9.1) и следующую (лис­тинг 9.2) программы, а также учитывая, что задача не требует для своего решения оконного интерфейса, в тексте использованы только те вызовы API, которые не затрагивают графический интерфейс. Конечно, нынче редко какое приложение не использует возможностей GUI, но зато в нашем случае сразу можно увидеть раз­ницу в организации параллельной работы запускаемых вычислений.

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

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

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

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

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

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

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

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

POSIX

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

Книги

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

Стандарт POSIX в редакции 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 - обязательный элемент современной дисциплины разработки прикладных систем.