структура UNIX
Розглянемо тепер коротко загальна будова UNIX як операційного середовища (більш докладний опис архітектури операційної системи UNIX см. [25]. [37] або [35]).
Центром ОС є, як було сказано, менеджер ресурсів і планувальник завдань. Функції цих частин системи затребувані, поки є хоч одна задача (т. Е. Завжди), функції до того ж працюють в режимі супервізора. В UNIX вони складають ядро системи (kernel). Ядро постійно знаходиться в пам'яті, обслуговуючи безперервний потік запитів на використання універсальних ресурсів системи: пам'яті і часу. В ядро UNIX. крім того, входить реалізація мережевих протоколів (були спроби виділити стек протоколів TCP / IP в окремий модуль, але це багато разів знижує продуктивність, оскільки реалізація деяких особливостей TCP / IP, як не дивно, вимагає жорсткої прив'язки до зовнішніх пристроїв і структурам ядра). Ядро UNIX надає програмам користувача уніфікований інтерфейс до ресурсів комп'ютера (так звані системні виклики. System calls) і містить всю непросту логіку розподілу ресурсів за завданнями, які в UNIX називаються процесами.
Мал. 5.1. Структура UNIX як операційного середовища
Насправді далеко не всі, що працює в режимі ядра (супервізора), зобов'язана бути присутньою в конкретній системі, запущеної на конкретному комп'ютері. Функції, які відповідають за роботу з найрізноманітнішими зовнішніми пристроями (які відрізняються логікою роботи), безглуздо включати в ядро все відразу. Окремо взятий комп'ютер не містить і сотої частини всіх пристроїв, які підтримує ця система. Більш того, найчастіше досить важко автоматично визначити марку пристрою, підключеного до системи; ще важче, не маючи величезною бази даних по всіх пристроях, визначити, якому з відомих пристроїв відповідає знайдене системою невідоме, і взагалі чи відповідає (т. е. чи можна з ним працювати як з дещо іншим, але відомим). А ось адміністратору системи достатньо для цього подивитися маркування на самій платі або почитати документацію. Так ми приходимо до поняття драйвера пристрою ( "драйвер" по-англійськи буде handler, а слово driver означає пристрій, яке що-небудь крутить або тягне, наприклад стрічкопротяжного. Однак пишуть по-англійськи носії інших мов часто говорять driver замість handler. плутанина неминуча, якщо не вникати кожен раз в те, про що мова). Драйвери включаються до складу ядра. якщо відповідні їм пристрої входять (або можуть входити) до складу комп'ютера. Одні драйвери (скажімо, шини PCI) є в системі майже завжди, інші написані спеціально для контролера якогось екзотичного пристрою. Існують драйвери. які не є інтерфейсної частиною зовнішнього пристрою, а реалізують додаткову функціональність самої системи (скажімо, драйвер файлової системи ISO9660, яка використовується на лазерних дисках).
У старих версіях UNIX (заснованих безпосередньо на BSD4.3 або UNIX SystemV різних редакцій) всі драйвери доводилося заздалегідь прікомпоновивать до ядра (т. Е. Користуватися компоновщиком ld, таким же, який застосовується при складанні програм). Більш того, запуск ld був своєрідною поступкою комерційних версій UNIX його некомерційному духу, тому що насправді драйвери компілювалися з вихідних текстів на мові Сі. як і всі ядро системи (так було, наприклад, в FreeBSD3. * і в Linux до версії 1.2). Процес компіляції ядра системи з вихідних текстів чи компонування його з об'єктних модулів носить назву збірки (пересборки) ядра і в багатьох системах практикується і донині.
Зі збільшенням розмірів оперативної пам'яті відпала необхідність економити байти на збірці ядра. в точності відповідного наявного профілю обладнання. Розробники намагаються зібрати ядро. що містить драйвери всіх найпопулярніших пристроїв, щоб воно, не займаючи занадто багато пам'яті, могло керувати системою на переважній більшості комп'ютерів. Таке ядро називається базовим (generic). Оскільки для пересборки ядра необхідні багато знань (як мінімум, потрібно розбиратися в архітектурі використовуваної версії UNIX. В архітектурі ЕОМ і особливо зовнішніх пристроїв), а потреба в цьому може виникнути при першій же установці системи, добре укомплектований базове ядро багато в чому полегшує життя недосвідченому користувачеві.
модулі ядра
Якщо базового ядра все-таки недостатньо, в сучасних системах багато драйверів можна завантажувати динамічно. з модулів ядра. Ядро. вже працює в пам'яті, можна доповнити, завантаживши такий модуль з файлу спеціального формату, після чого перекомпонувати ядро на ходу (спеціальним компоновщиком). У ці модулі можна винести необов'язкові функціональності системи (наприклад, фільтрацію мережевих пакетів), після чого базове ядро стане ще менше, проте процес завантаження ускладниться, так як деякі з підвантажуваних модулів знадобляться ядру вже при старті системи, коли доступу до файлів може і не бути . Типовий приклад: для роботи з диском ядру потрібен драйвер дискового масиву (RAID-контролера), який разом з програмою завантаження і компонування модулів на цьому масиві і знаходиться. Різні системи виходять з цієї ситуації по-різному.
Модулі ядра працюють в режимі ядра. тому звертатися з ними слід вкрай обережно: помилка в такому модулі (скажімо, запис невідомо чого невідомо куди в пам'ять) настільки ж фатальна, як і помилка ядра. і в кращому випадку викличе крах системи (в гіршому випадку система її помітить не відразу). Функції модулів з точки зору ОС збігаються з функціями ядра. організація інтерфейсу до ресурсів і додаткова логіка роботи системи.
Інші частини UNIX запускаються вже як процеси в режимі користувача. З ядром взаємодіють функціональні підсистеми (служби), тобто набори програмних засобів, що виконують певну функцію (наприклад, система друку, система передачі пошти і т. Д.). Керуючий центр функціональної підсистеми - так званий демон (daemon, в перекладах з грецької званий "даймон"). Як сказано в "Посібнику системного адміністратора UNIX" ([33]), "Даймон не може виступати в ні злу, ні добра, він тільки визначає характер і особистість людини. Він більше схожий на ангела-хранителя.". Наявність рогів і тризуба у демонів BSD ще ні про що не говорить, наприклад, демона FreeBSD звуть зовсім по-людськи - Чак (Chuck). Істота, що з'являється в Linux. хоч і зветься Такс (Tux), не має ні рогів, ні тризуба, тому що "за національністю" - пінгвін. Демон - це процес. який запускається при старті UNIX для обслуговування запитів до функціональної підсистеми. Користувачеві запускати його нема чого, він працює завжди. Саме демон обмінюється даними з ядром системи, часто він тримає чергу призначених для користувача запитів, працює з мережею і т. Д.
Звертатися до системних викликів можуть, звичайно, не тільки демони. але і взагалі будь-які програми. В UNIX входить чимало програм, за допомогою яких можна вирішувати різноманітні інструментальні (т. Е. Пов'язані з роботою самої системи) завдання. Це так звані системні утиліти. Вони використовуються в першу чергу самою системою (причому викликаються, як правило, з командних сценаріїв. Про яких розповідається в лекції 11) і системним адміністратором - для управління системою. Однак і користувач, що не володіє правами адміністратора, цілком може задіяти системні утиліти. якщо вони допомагають йому в роботі, а системі не заважають (наприклад, створювати файлову систему на дискеті, переглядати стан системи або демонів і т. п.).
Програмні продукти і пакети
Зрозуміло, що на будь-яку прикладну область утиліт не напасешся. Чим складніше і далі від інструментальної області завдання, тим менше сенсу включати інструменти її рішення в систему. Проте, якщо вже завдання є, значить, комусь доведеться її вирішувати. Такі спеціалізовані набори програм хотілося б мати якщо не в самій системі, то десь "поряд", щоб, як тільки з'явиться користувач зі своїми завданнями, надати йому кошти їх вирішення. І вже, звичайно метаінструментарій - кошти виготовлення таких інструментів - в системі повинен бути (метаінструментарій - це кошти програмування і взагалі розробки програм: мови програмування, загальні, інтерфейсні та предметно-орієнтовані бібліотеки, RAD - кошти швидкої розробки і т. П.). Такий набір програм для вирішення прикладних завдань називається програмним продуктом.
Для того щоб оперативно додавати програмний продукт в систему або видаляти його звідти, необхідно заздалегідь домовитися про розміщення в файлової системі всіх вхідних в нього файлів. Запам'ятавши кожен файл з повним ім'ям. ми отримаємо архів. цілком визначає розташування програмного продукту в системі. Такий архів в UNIX називається пакетом. Ми можемо встановлювати пакет в систему і видаляти його, знаючи, що записуємо і видаляємо файли, що належать тільки йому. У пакеті можуть зберігатися не тільки програмні продукти. але і взагалі будь-які "цеглинки", з яких можна складати систему: утиліти. драйвери. документація, шрифти і все інше. Якщо при установці або видаленні пакета потрібно виконати якісь дії (наприклад, зареєструвати встановлюється шрифт), до нього додаються інсталяційний сценарій і сценарій видалення.
Система, налаштована на вирішення певних завдань, не обов'язково повинна містити всі можливі пакети. Як правило, в дистрибутив UNIX входить кілька тисяч пакетів різного призначення і обсягу, від утиліти. повідомляла, в якій фазі сьогодні знаходиться місяць, до видавничої системи. Насправді їх встановлюють кілька сотень.