Олексій Федорчук
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, призначений для головних системних бібліотек.
Коренева файлова система
Коренева файлова система є нерозділюваною (тобто не призначеною для спільного використання різними машинами мережі) і незмінною (тобто зміни до неї може вносити тільки адміністратор системи, але не програми користувача і, тим більше, не користувачі). Причому вкрай не рекомендується створювати в ній підкаталоги понад передбачені стандартом (і перераховані вище).
Наповнення кореневої файлової системи підбирається з таким розрахунком, щоб машина могла стартувати і зберігала б мінімальну функціональність навіть при аварійному завантаженні (або в режимі одного користувача), коли всі інші файлові системи не монтуються (і, відповідно, такі її гілки, як /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?
POSIX (вимовляється як «позикс») - це портативний інтерфейс операційних систем. Але що це означає? По-перше, потрібно позначити область дії поняття «портативність», у даному випадку, і визначитися з поняттям «інтерфейс». Щоб з'ясувати це, необхідно відштовхуватися від того, що обидва поняття нерозривно пов'язані.
"Портативність", у контексті стандарту POSIX, відноситься до вихідного коду(Не до бінарників, які з цих вихідників збираються). Тепер з'ясуємо, що таке "інтерфейс". У програмуванні «інтерфейс» - це взаємодія вашого коду з рештою коду. Інтерфейс чекає від вашого коду надання певної інформації. Ваш код, своєю чергою, передбачає отримання певної інформації від інтерфейсу. Гарний приклад- функція fopen() у мові Сі. Вона чекає на інформацію з двох частин: шлях до файлу і режим, в якому він буде відкритий. За допомогою цих даних операційна система повертає інший вид інформації, який називається «дескриптор файлу». Дескриптор файлу може бути використаний для читання або запису файлу. Це і є інтерфейс. З усього цього випливає, що POSIX-сумісний код може бути скомпільований під будь-яку POSIX-сумісну операційну систему без серйозних змін, отже, він буде портативним.
Список інтерфейсів, що відносяться до стандарту POSIX, знаходиться, проте, навіть незважаючи на його величезну довжину, цілком можливо, що він неповний. POSIX не обмежується системними викликами, він також визначає стандарти для оболонок операційних систем (шеллів, інакше – інтерфейсів) командного рядка), системних утиліт, на кшталт «awk» або «echo», системних бібліотек та багато іншого.
Стандарт POSIX з'явився у вигляді проекту Річарда Столлмана у 1985 році та надалі був оформлений як IEEE Std 1003.-1998. Як видно з назви, 1998 був роком офіційної публікації. З того часу було випущено велику кількість доповнень і розширень до POSIX, який поступово перетворюється на ціле сімейство стандартів, формально відоме як IEEE 1003, визнане як міжнародне, з позначенням SO/IEC 9945, яке просто називається стандарт сімейства POSIX.
Операційній системі зовсім необов'язково бути POSIX-сумісною або тим більше мати сертифікат POSIX, проте це дозволяє розробникам створювати додатки, інструменти та платформи, не переписуючи код раз-по-раз, а лише доповнювати і підключатися до вже готового. Також зовсім не обов'язково писати POSIX-сумісний код, проте це значно покращує переносимість проектів між операційними системами. Це означає, що вміння писати код, який сумісний зі стандартом POSIX, є цінним саме собою, і, безумовно, дуже корисно для кар'єри. Великі проекти, такі як Gnome або KDE, дотримуються стандарту POSIX, що гарантує їхню роботу на різних операційних системах. Підсистема POSIX реалізована навіть у останніх випусках Windows. Linux, як відомо, підтримує більшість системних викликів, що належать до стандарту POSIX, так само як і велике розширення до нього, що називається «Стандартна база Linux», яка призначена для об'єднання дистрибутивів Linux у плані підтримки вихідних кодів та бінарних даних.
Сподіваюся, ми пролили світло на запитання, що таке POSIX. Маєте цікавою інформацієюна тему? Будь ласка, поділіться їй у коментарях.
ПО) - завдання виняткової важливості та складності; у наш час ця обставина навряд чи потребує розлогих обґрунтувань. Один із загальноприйнятих способів підвищення мобільності ПЗ - стандартизація оточення додатків: програмних інтерфейсів, що надаються, утиліт і т.п. на рівні системних сервісівподібне оточення описує стандарт POSIX (Portable Operating System Interface – мобільний інтерфейс операційної системи); назва запропонована відомим спеціалістом, засновником Фонду вільного програмного забезпечення Річардом Столменом.Ми будемо розглядати найсучаснішу з доступних версій стандарту POSIX, у редакції 2003 р., яку можна назвати "стандартом втричі", а саме: стандартом IEEE Std 1003.1, Технічним стандартом Open Group і (див. [6]), що для нас важливіше всього, міжнародним стандартом ISO / IEC 9945 (див. [1], [2], [3], [4]).
Історія створення цієї версії така. На початку 1998 р. представники трьох організацій – Комітету зі стандартів мобільних додатківІнституту інженерів з електротехніки та електроніки, Open Group і робочої групи 15 підкомітету 22 спільного технічного комітету 1 (JTC1/SC22/WG15) Міжнародної організації зі стандартизації - розпочали консультації з питання злиття та розвитку курованих ними стандартів інтерфейсів до системних сервісів: IEEE St1. 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 (IEEE Portable Operating System Interface for Computer Environments, IEEE 1003.1). Початковий варіант стандарту POSIX з'явився у 1990 р. і був призначений для UNIX-систем, перші версії яких з'явилися у 70-х роках минулого століття. Специфікації POSIX визначають стандартний механізм взаємодії прикладної програми та операційної системи та в даний час включають набір більш ніж з 30 стандартів. Для ОСРВ найбільш важливі сім із них (1003.1a, 1003.1b, 1003.1c, 1003.1d, 1003.1j, 1003.21, 1003.2h), але широку підтримку в комерційних ОС отримали лише три перші.
Незважаючи на явно застарілі положення стандарту POSIX і велику затребуваність оновлень стандартизації для ОСРВ, помітного просування у цьому напрямі немає.
Стандарт POSIX створено як стандартний інтерфейс сервісів операційних систем. Цей стандарт дає можливість створювати програми, що переносяться. Згодом цей стандарт було розширено особливостями режиму реального часу.
Специфікації POSIX задають стандартний механізм взаємодії програми та ОС. Необхідно відзначити, що стандарт POSIX тісно пов'язаний з ОС Unix, проте розробники багатьох ОСРВ намагаються витримати відповідність цьому стандарту.
Відповідність стандарту POSIX для ОС та апаратної платформи має бути сертифікована за допомогою прогону на них тестових наборів. Однак, якщо ОС не є Unix-подібною, витримати цю вимогу стає непростим завданням. Тестові набори існують лише для POSIX 1003.1a. Оскільки структура POSIX є сукупністю необов'язкових можливостей, постачальники ОС можуть реалізувати лише частину стандартного інтерфейсу, і при цьому говорити про POSIX-компліантність своєї системи.
Незважаючи на те, що стандарт POSIX виріс з Unix, він зачіпає основні абстракції операційних систем, а розширення реального часу застосовні до всіх ОСРВ.
До теперішнього часу стандарт POSIX розглядається як сімейство споріднених стандартів: IEEE Std 1003.n (де n – це номер).
СТАНДАРТИ
Сергій Золотарьов,
Метою цієї статті є спроба внести певну ясність в історію розвитку стандарту POSIX стосовно операційних систем реального часу (ОС РВ).
Як вступ: навіщо потрібна стандартизація програмного інтерфейсу?
Однією з найважливіших властивостей стандарту POSIX є те, що він визначає стандартизований програмний інтерфейс, якого повинні дотримуватися розробники складних програмно-апаратних систем. Творці цих систем змушені стикатися з такими вимогами, як стислий термін виходу ринку (через жорсткої конкуренції), мінімізація витрат і прискорення повернення інвестицій. При цьому левова частка витрат, зумовлених уповільненням процесу розробки, пов'язана з тим, що програмістам доводиться "винаходити велосипед", знову і знову реалізовуючи вже давно функціональність. Адже цього можна було б уникнути за рахунок:
Повторного використання коду з минулих та паралельних проектів;
Перенесення коду з інших ОС;
Залучення розробників з інших проектів (зокрема з інших ОС).
Все це можливо завдяки застосуванню ОС зі стандартним API. Причому якщо у першому випадку організації достатньо мати якийсь внутрішній стандарт (що особливо для фірмових ОС), то другі два випадки вимагають наявності загальновизнаних стандартів - наприклад, POSIX.
Таким чином, використовуючи як платформу для своїх проектів POSIX-сумісну ОС, розробник отримує можливість перенести готовий код на рівні вихідного тексту як зі своїх минулих або паралельних проектів, так і з проектів третіх фірм. Це не тільки суттєво скорочує термін розробки ПЗ, але й підвищує його якість, оскільки перевірений код завжди містить менше помилок.
Хто є хто у справі розвитку POSIX
І почнемо ми з самого стандарту POSIX, і з упорядкування ролі організацій, що у роботі над ним.
Перший учасник – це IEEE(Institute of Electrical and Electronics Engineers, Інститут інженерів з електрики та електроніки), громадська некомерційна асоціація професіоналів. IEEE веде свою історію з 1884 р. (формально - з 1963-го), об'єднує 380 000 індивідуальних членів зі 150 країн, видає третину технічної літератури щодо застосування комп'ютерів, управління, електро- та інформаційних технологій, а також понад 100 журналів, популярних серед професіоналів; крім того, асоціація проводить за рік понад 300 великих конференцій. IEEE брала участь у розробці понад 900 чинних стандартів (www.ieee.ru/ieee.htm). Сьогодні цей інститут займається підготовкою, погодженням, твердженням, публікацією стандартів, але за своїм формальним статусом не має повноважень приймати такі документи, як міжнародні чи національні стандарти. Тому термін "стандарт" у розумінні IEEE швидше означає "специфікація", що більш відповідає статусу документів, що приймаються асоціацією. Відповідно до IEEE бере участь у програмах низки міжнародних та регіональних організацій - IEC, ISO, ITU (International Telecommunication Union), ETSI (European Telecommunications Standards Institute), CENELEC (European Committee for Electrotechnical Standartization) та у національних програмах, наприклад у програмі як ANSI.
До складу IEEE входить PASC (Portable Application Standards Committee; www.pasc.org/) – комітет асоціації, який займається розробкою сімейства стандартів POSIX. Раніше PASC був відомий як Технічний комітет з операційних систем.
Другий учасник робіт - ANSI (American National Standards Institute, Американський національний інститут стандартів; www.ansi.org) - приватна некомерційна організація, яка адмініструє та координує у США діяльність з питань стандартизації. У ній працює лише 75 осіб, але членами ANSI є понад 1000 компаній, організацій, урядових агенцій та інститутів. ANSI представляє США у двох основних міжнародних організаціях зі стандартизації – ISO та IEC.
Третій учасник - ISO(International Organization for Standardization, Міжнародна організація зі стандартизації; www.iso.org). Вона створена в 1946 р. за рішенням Комітету з координації стандартів і Генеральної асамблеї ООН і офіційно розпочала роботу 23 лютого 1947 р. Швейцарія). Стандарти ISO розробляються в технічних комітетах, першим результатом діяльності яких є документ Draft International Standard (DIS), що перетворюється після кількох погоджень на Final Draft International Standard (FDIS). Після цього питання про схвалення цього документавиноситься на голосування; за позитивного результату він стає міжнародним стандартом.
І нарешті, - IEC(International Electrotechnical Commission, Міжнародна електротехнічна комісія - МЕК; www.iec.ch/), заснована в 1906 р. IEC готує та публікує міжнародні стандарти для всіх електричних, електронних та пов'язаних з ними технологій. Станом на 1 листопада 2004 р. дійсними членами цієї комісії були національні комітети 64 країн. IEC видає також і рекомендації, що виходять англійською та французькою мовами та мають статус міжнародних стандартів. На їх основі розробляються регіональні та національні стандарти. За підготовку стандартів у різних сферах діяльності IEC відповідають технічні комітети (ТК), у роботі яких беруть участь і національні комітети, зацікавлені у діяльності тієї чи іншої ТК.
IEC- ключова організація у підготовці міжнародних стандартів з інформаційним технологіям. У цій галузі діє об'єднаний технічний комітет з інформаційних технологій - JTC 1, сформований у 1987 р. відповідно до угоди між IEC та ISO. JTC1 має 17 підкомітетів, що займаються всіма розробками - від програмного забезпеченнядо мов програмування, комп'ютерної графікита редагування зображень, взаємозв'язку обладнання та методів безпеки.
Підготовка нових стандартів IEC включає кілька стадій (попередня стадія пропозиції, підготовча стадія технічного комітету стадія запиту схвалення публікації). Якщо заплановано, що документ IEC стане лише технічною специфікацією, а не міжнародним стандартом, переглянута версія документа надсилається до центрального офісу для видання. На вироблення заключного проекту міжнародного стандарту (FDIS) відводиться чотири місяці. Якщо його схвалять усі члени технічного комітету, він прямує до центрального офісу для публікації без стадії схвалення FDIS. Після цього FDIS потрапляє до національних комітетів, які мають затвердити протягом двох місяців. FDIS вважається схваленим, якщо за нього проголосувало понад дві третини національних комітетів, а кількість негативних голосів не перевищує 25%. Якщо документ не схвалено, він надсилається для перегляду до технічних комітетів та підкомітетів. Стандарт має бути опублікований не пізніше ніж через два місяці після схвалення FDIS.
До вироблення та прийняття стандартів POSIX мають відношення ще кілька організацій.
Open Group- Міжнародна організація зі стандартизації програмного забезпечення, яка об'єднує майже 200 виробників та користувацьких спільнот, що працюють в галузі інформаційних технологій (www.opengroup.org/). OpenGroup створена в 1995 р. шляхом злиття двох своїх попередників: X/Open та Open Software Foundation (OSF). Open Group спеціалізується на розробці методологій сертифікації програмного забезпечення та проведенні тестування на відповідність певним вимогам. Зокрема, Open Group займається сертифікацією для таких напрямків, як COE Platform, CORBA, LDAP, Linux Standard Base, Schools Interoperability Framework (SIF), S/MIME Gateway, Single UNIX Specification, Wireless Application Protocol Specifications (WAP) і, нарешті, сімейство стандартів POSIX (www.opengroup.org/certification/).
AustinCommonStandardsRevisionGroup (CSRG)- об'єднана технічна робоча група, утворена в 2002 р. ISO, IEC та Open Group для створення та супроводу останніх версійстандарту 1003.1, який формуватиметься на основі ISO/IEC 9945-1-1996, ISO/IEC 9945-2-1993, IEEE Std 1003.1-1996, IEEE Std 1003.2-1992 та Single UNIX Specification. 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). у рамках 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 (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. стандарт ISO/IEC 9945-1:1990. Набори тестів для FIPS 151-2 базувалися на IEEE 2003.1-1992 "Standard for Test Methods for Measuring Conformance to POSIX".
NIST розрізняє дві методології сертифікації: самосертифікація (self-certification) та сертифікація акредитованими в IEEE тестовими лабораторіями (Accredited POSIX Testing Laboratories – APTL). У першому випадку компанія проводить тестування самостійно, але за планом, затвердженим у NIST. У другий випадок тестування виконується незалежної лабораторією з допомогою автоматизованих наборів тестів. Усього було акредитовано дві APTL-лабораторії: Mindcraft (www.mindcraft.com) та Perennial (www.peren.com).
У 1997 р. NIST/ITL оголосила про намір припинити сертифікацію по FIPS 151-2 наприкінці поточного року (офіційно - 31 грудня 1997 р.), у той же час Open Group повідомила про те, що збирається взяти на себе з 1 жовтня того. ж року сервіс із сертифікації відповідно до FIPS 151-2, заснований на програмі NIST/ITL. Ті ж функції з 1 січня 1998-го взяла на себе Асоціація зі стандартизації IEEE (IEEE-SA), а також на основі FIPS 151-2.
У 2003 р. IEEE-SA та Open Group оголосили про початок нової спільної програми із сертифікації останніх версій POSIX, починаючи з IEEE 1003.1(tm) 2001. Зараз Open Group має кілька наборів тестів, які покривають IEEE Std 1003.1-1996, IEEE .
2-1992, IEEE Std 1003.1-2003 та IEEE Std 1003.13-1998 (www.opengroup.org/testing/testsuites/posix.html). Продукт вважається сертифікованим за POSIX, якщо він пройшов повну процедуру сертифікації, за результатами тестування задовольняє всі пред'явлені вимоги та занесений до офіційного реєстру сертифікованих продуктів.
Набори тестів включають:
VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm) - набір conformance-тестів для системних інтерфейсів IEEE Std 1003.1-1990;
VSPSE54 (www.opengroup.org/testing/testsuites/VSPSE54.htm) - набір conformance-тестів для IEEE Std 1003.13-1998 Profile PSE54 (багатоцільовий реальний час);
VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm) - набір conformance-тестів для системних інтерфейсів IEEE Std 1003.1-2003 (тільки обов'язкові частини);
VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpcts2003.htm) – набір conformance-тестів для IEEE Std 1003.1-2003 (shell and utilities – тільки обов'язкові частини).
Крім того, Open Group розробила тести для стандартів POSIX Realtime та профілю стандартів Embedded POSIX. Набір тестів для POSIX Realtime (www.opengroup.org/testing/testsuites/realtime.html) включає наступні тести:
IEEE POSIX 1003.1b-1993/1003.1i-1995 Realtime extension and IEEE POSIX 1003.1,2003 Edition;
IEEE Std POSIX 1003.1c-1995 Threads (pthreads) extension and IEEE POSIX 1003.1,2003 Edition;
IEEE POSIX 1003.1d-1999 Additional Realtime Extension and IEEE POSIX 1003.1,2003 Edition;
IEEE POSIX 1003.1j-2000 Advanced Realtime Extension and IEEE POSIX 1003.1,2003 Edition;
IEEE POSIX 1003.1q-2000 Trace та 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. 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.