Олексій Федорчук
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 та ОС РВ: спроба систематизації

Сергій Золотарьов, Микола Горбунов

Метою цієї статті є спроба внести певну ясність в історію розвитку стандарту 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) – комітет асоціації, який займається розробкою сімейства стандартів 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. 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 un IX(Інтерфейс, що переноситься операційних системдля Unix). POSIX розроблявся для UNIX-подібних операційних систем (їх перші версії ведуть свій відлік початку 1970-х) з метою забезпечення переносимості додатків лише на рівні вихідних текстів.

Початковий опис інтерфейсу було опубліковано в 1986 р., тоді він називався IEEE-IX (IEEE"s version of UNIX). Однак назва швидко змінилася, перетворившись на POSIX, і вже в наступній публікації (ще в 1986 р.) використовувався цей новий варіант Певний час під POSIX розумілося посилання (або синонім) на групу родинних документів IEEE 1003.1-1988 та частини ISO/IEC 9945, а як закінчений і затверджений міжнародний стандарт ISO/IEC 9945.1:1990 POSIX був прийнятий в 1990 р. стандартний механізм взаємодії прикладної програми та ОС та в даний час включають понад 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, Open Group Technical Standard Base Specifications, Issue 6 і включає IEEE Std 1003.1-2001, 2001-2001. 1-2002 та IEEE Std 1003.1-2001/Cor 2-2004.

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

Для операційних систем реального часу найбільш важливими є сім специфікацій стандарту (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21), але широку підтримку в комерційних ОС отримали лише три:

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

Крім зазначених стандартів, важливими для ОС РВ є такі стандарти, які були реалізовані в рамках роботи над проектом 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 15 -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, IE9 St2 1 , 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 та IEEE POSIX 1003.1,2003 Edition та 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 англійськоючасто використовуються не один, а цілих три терміни. На жаль, вони подібні за значенням і часто перекладаються однаково, що вносить певну плутанину. Терміни такі:

• compatibility (буквально - "сумісність");
• с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 в 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. Національний Institute of Standards and Technology, PCTS: 151-2, POSIX Test Suite.
6. POSIX: Certified by IEEE і Open Group. Certified Policy. The Open Group, October 21, 2003, Revision 1.1.

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

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

Що таке POSIX?

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

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

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

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

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

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

- (IPAEng|ˈpɒzɪks) or Portable Operating System Interface cite web | title = POSIX | url = http://standards.ieee.org/regauth/posix/ | work = Standards | publisher = IEEE] is the collective name of 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.

Posix- est le nom d une famille de standards définie depuis 1988 par l IEEE et formellement désignée IEEE 1003.

POSIX- es el acrónimo de Portable Operating System Interface; la X viene de UNIX como seña de identitat de la API. El terme fue sugerido por Richard Stallman en resposta a la demanda de la IEEE, que buscaba un numero 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 com Sistema Operativo Portable basado en UNIX). Estos son una familia de estándares de llamadas al sistema… … Enciclopedia Universal

POSIX- (Portable Operating System Interface базується на unix) n. колекція стандартів для операційних систем, які базуються на 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…

Книги

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

Назва Posix утворена від "Portable Operating System Interface", що означає приблизно "інтерфейс переносних операційних систем". Це не один стандарт, а ціле сімейство, розроблене Інститутом інженерів з електротехніки та радіоелектроніки (Institute for Electrical and Electronics Engineers – IEEE). Стандарти Posix були також прийняті як міжнародні стандарти ISO (International Organization for Standardization, Міжнародна організація зі стандартизації) та IEC (International Electrotechnical Commission, Міжнародна електротехнічна комісія), або ISO/IEC. Стандарти Posix пройшли кілька етапів розробки.

Стандарт IEEE 1003.1-1988 (317 сторінок) був першим стандартом Posix. Він визначав інтерфейс взаємодії мови С з ядром Unix-типу в наступних областях: примітиви для реалізації процесів (виклики fork, exec, сигнали та таймери), середовище процесу (ідентифікатори користувачів, групи процесів), файли та каталоги (всі функції вводу-виводу) , робота з терміналом, бази даних системи (файли паролів та груп), формати архівів tar та cpio.

ПРИМІТКА

Перший стандарт Posix вийшов у робочому варіанті під назвою IEEEIX у 1986 році. Назва Posix була запропонована Річардом Штолманом (Richard Stallman).

Потім вийшов стандарт IEЕЕ 1003.1-1990 (356 сторінок). Він одночасно був і міжнародним стандартом ISO/IEC 9945-1:1990. У порівнянні з версією 1988 зміни в версії 1990 були мінімальними. До заголовку було додано: "Part 1: System Application Program Interface (API)" ("Частина 1: Системний інтерфейс розробки програм (API) [Мова С])", і це означало, що стандарт описував програмний інтерфейс (API) мови С .

IEEE 1003.2-1992 вийшов у двох томах загальним обсягом близько 1300 сторінок, і його заголовок містив рядок "Part 2: Shell and Utilities" (Частина 2: "Інтерпретатор та утиліти"). Ця частина визначала інтерпретатор (заснований на Bourne shell Unix System V) і близько ста утиліт (програм, які зазвичай викликаються з інтерпретатора - від awk і basename до vi і уасс). У цій книзі ми будемо посилатися на цей стандарт під назвою Posix. 2.

IEEE 1003.1b-1993 (590 сторінок) спочатку був відомий як IEEE P1003.4. Цей стандарт був доповненням до стандарту 1003.1-1990 і включав розширення реального часу, розроблені робочою групоюР1003.4: синхронізацію файлів, асинхронне введення-виведення, семафори, управління пам'яттю, планування виконання (scheduling), годинник, таймери та черги повідомлень.

IEEE 1003.1, видання 1996 року (743 сторінки), включає 1003.1-1990 (базовий інтерфейс API), 1003.1b-1993 (розширення реального часу), 1003.1-1995 (Pthreads - програмні потоки139 і програмні потоки19) 1003.1b). Цей стандарт також називається ISO/IEC 9945-1: 1996. До нього були додані три розділи про потоки та додаткові розділи щодо синхронізації потоків (взаємні винятки та умовні змінні), планування виконання потоків, планування синхронізації. У цій книзі ми називаємо цей стандарт Posix.1.

ПРИМІТКА

Понад чверть із 743 сторінок стандарту являли собою додаток, під назвою «Rationale and Notes» («Обгрунтування та примітки»). Це обґрунтування містить історичну інформацію та пояснення причин, з яких деякі функції були або не включені до стандарту. Часто обґрунтування виявляється не менш корисним, ніж стандарт.

На жаль, стандарти IEEE не є вільно доступними через Інтернет. Інформація про те, де можна замовити книгу, наведена в бібліографії під посиланням . Зверніть увагу, що семафори були визначені у стандарті розширень реального часу, окремо від взаємних винятків та умовних змінних (які були визначені у стандарті Pthreads), що пояснює деякі відмінності в інтерфейсах API цих засобів.

Зрештою, зауважимо, що блокування читання-запису не є частиною стандартів Posix. Про це докладніше розказано у розділі 8.

У майбутньому планується вихід нової версії IEEE 1003.1, що включає стандарт P1003.1g, мережеві інтерфейси(Сокети та XTI), які описані в першому томі цієї книги.

У передмові стандарту Posix.1 1996 стверджується, що стандарт ISO/IEC 9945 складається з наступних частин:

1. Системний інтерфейс розробки програм (API) (мова С).

2. Інтерпретатор та утиліти.

3. Адміністрування системи (у створенні).

Частини 1 і 2 є те, що ми називаємо Posix.1 і Posix.2.

Робота над стандартами Posix постійно продовжується, і авторам книг, з ними пов'язаних, доводиться займатися стріляниною по мішені, що рухається. Про поточному станістандартів можна дізнатись на сайті http://www.pasc.org/standing/sd11.html.