Тенденції в структурній побудові ОС: монолітні системи, багаторівневі системи, модель клієнт-сервер та мікро ядра.

Операційні системи пройшли тривалий шлях розвитку від монолітних систем до добре структурованих модульних систем, здібних до розвитку, розширення і легкого перенесення на нові платформи.

Монолітні системи

У загальному випадку "структура" монолітної системи є відсутністю структури (малюнок 4.1). ОС написана як набір процедур, кожна з яких може викликати інші, коли їй це потрібно. При використанні цієї техніки кожна процедура системи має добре певний інтерфейс в термінах параметрів і результатів, і кожна вольна викликати будь-яку іншу для виконання деякої потрібної для неї корисної роботи.

Мал. 4.1. Монолітна структура ОС

Для побудови монолітної системи необхідно скомпілювати всі окремі процедури, а потім зв'язати їх разом в єдиний об'єктний файл за допомогою компонувальника (прикладами можуть служити ранні версії ядра UNIX або Novell NetWare). Кожна процедура бачить будь-яку іншу процедуру (на відміну від структури, що містить модулі, в якій велика частина інформації є локальною для модуля, і процедури модуля можна викликати тільки через спеціально певні точки входу).

Проте навіть такі монолітні системи можуть бути небагато структурованими. При зверненні до системних викликів, підтримуваних ОС, параметри поміщаються в строго певні місця, такі, як регістри або стек, а потім виконується спеціальна команда переривання, відома як виклик ядра або виклик супервізора. Ця команда перемикає машину з режиму користувача в режим ядра, званий також режимом супервізора, і передає управління ОС. Потім ОС перевіряє параметри виклику для того, щоб визначити, який системний виклик повинен бути виконаний. Після цього ОС індексує таблицю, що містить посилання на процедури, і викликає відповідну процедуру. Така організація ОС припускає наступну структуру:

1. Головна програма, яка викликає необхідні сервісні процедури.

2. Набір сервісних процедур, що реалізовують системні виклики.

3. Набір утиліт, обслуговуючих сервісні процедури.

У цій моделі для кожного системного виклику є одна сервісна процедура. Утиліти виконують функції, які потрібні декільком сервісним процедурам. Це ділення процедур на три шару показано на малюнку 4.2.

 

Мал. 4.2. Проста структуризація монолітної ОС

Багаторівневі системи

Узагальненням попереднього підходу є організація ОС як ієрархії рівнів. Рівні утворюються групами функцій операційної системи - файлова система, управління процесами і пристроями і т.п. Кожен рівень може взаємодіяти тільки з своїм безпосереднім сусідом - выше- або нижележащим рівнем. Прикладні програми або модулі самої операційної системи передають запити вгору і вниз по цих рівнях.

Першою системою, побудованою таким чином була проста пакетна система THE, яку побудував Дейкстра і його студенти в 1968 році.

Система мала 6 рівнів. Рівень 0 займався розподілом часу процесора, перемикаючи процеси по перериванню або після закінчення часу. Рівень 1 управляв пам'яттю - розподіляв оперативну пам'ять і простір на магнітному барабані для тих частин процесів (сторінок), для яких не було місця в ОП, тобто шар 1 виконував функції віртуальної пам'яті. Шар 2 управляв зв'язком між консоллю оператора і процесами. За допомогою цього рівня кожен процес мав свою власну консоль оператора. Рівень 3 управляв пристроями введення-висновку і буферизував потоки інформації до них і від них. За допомогою рівня 3 кожен процес замість того, щоб працювати з конкретними пристроями, з їх різноманітними особливостями, звертався до абстрактних пристроїв введення-висновку, що володіють зручними для користувача характеристиками. На рівні 4 працювали призначені для користувача програми, яким не треба було піклуватися ні про процеси, ні про пам'ять, ні про консоль, ні про управління пристроями введення-висновку. Процес системного оператора розміщувався на рівні 5.

У системі THE багаторівнева схема служила, в основному, цілям розробки, оскільки всі частини системи компонувалися потім в загальний об'єктний модуль.

Подальше узагальнення багаторівневої концепції було зроблене в ОС MULTICS. У системі MULTICS кожен рівень (званий кільцем) є більш привілейованим, ніж вищерозміщений. Коли процедура верхнього рівня хоче викликати процедуру нижележащего, вона повинна виконати відповідний системний виклик, тобто команду TRAP (переривання), параметри якої ретельно перевіряються перед тим, як виконується виклик. Хоча ОС в MULTICS є частиною адресного простору кожного призначеного для користувача процесу, апаратура забезпечує захист даних на рівні сегментів пам'яті, вирішуючи, наприклад, доступ до одних сегментів тільки для запису, а до інших - для читання або виконання. Перевага підходу MULTICS полягає в тому, що він може бути розширений і на структуру призначених для користувача підсистем. Наприклад, професор може написати програму для тестування і оцінки студентських програм і запустити цю програму на рівні n, тоді як студентські програми працюватимуть на рівні n+1, так що вони не зможуть змінити свої оцінки. Багаторівневий підхід був також використаний при реалізації різних варіантів ОС UNIX. Хоча такий структурний підхід на практиці зазвичай працював непогано, сьогодні він все більше сприймається монолітним. У системах, що мають багаторівневу структуру було нелегко видалити один шар і замінити його іншим через множинність і розмитість інтерфейсів між шарами. Додавання нових функцій і зміна що існують вимагало хорошого знання операційної системи і маси часу. Коли стало ясно, що операційні системи живуть довго і повинні мати можливості розвитку і розширення, монолітний підхід став давати тріщину, і на зміну йому прийшла модель клієнт-сервер і тісно пов'язана з нею концепція мікроядра.