Першою системою, побудованою таким чином була проста пакетна система the, яку побудував Дейкстра і його студенти в 1968 році.
Перші багаторівневі ОС мали 6 рівнів. Головна особливість таких ОС - розділення функцій між рівнями:
1-ий рівень - розподіл програмного часу;
2-ий рівень - зв'язок між консоллю оператора і додатками, що виконуються;
3-ій рівень - питання введення-виводу;
4-ий рівень - питання виділення пам'яті;
5-ий рівень - функціонування самих додатків ;
6-ий рівень - рівень системного адміністратора.
ОС такого типа знайшли відображення в перших версіях систем UNIX, де було
менше рівнів з визначуваними привілеями. Введення привілеїв дозволило забезпечити саму ОС.
Хоча такий структурний підхід на практиці зазвичай працював непогано, сьогодні він все більше сприймається монолітним. У системах, що мають багаторівневу структуру було нелегко видалити один рівень і замінити його іншим через множинність і розмитість інтерфейсів між рівнями. Додавання нових функцій і зміна що існують вимагало хорошого знання операційної системи і маси часу. Коли стало ясно, що операційні системи живуть довго і повинні мати можливості розвитку і розширення, монолітний підхід почав давати тріщину, і на зміну йому прийшла модель клієнт-сервер і тісно пов'язана з нею концепція мікроядра.
Модель клієнт-сервер і мікроядра
Модель клієнт-сервер - це ще один підхід до структуризації ОС. У широкому сенсі модель клієнт-сервер передбачає наявність програмного компонента споживача якого-небудь сервісу - клієнта, і програмного компонента постачальника цього сервісу - сервера. Взаємодія між клієнтом і сервером стандартизується, так що сервер може обслуговувати клієнтів, реалізованих різними способами і, можливо, різними виробниками. При цьому головною вимогою є те, щоб вони запрошували послуги сервера зрозумілим йому способом. Ініціатором обміну зазвичай є клієнт, який посилає запит на обслуговування серверу, що знаходиться в стані чекання запиту. Один і той же програмний компонент може бути клієнтом по відношенню до одного вигляду послуг, і сервером для іншого вигляду послуг. Модель клієнт-сервер є швидше зручним концептуальним засобом ясного представлення функцій того або іншого програмного елементу в тій або іншій ситуації, ніж технологією. Ця модель успішно застосовується не лише при побудові ОС, але і на всіх рівнях програмного забезпечення, і має в деяких випадках вузький, специфічний сенс, зберігаючи, природно, при цьому всі свої спільні межі.
Рис. 1.3. Структура ОС клієнт-сервер
Стосовно структуризації ОС ідея полягає в розбитті її на декілька процесів - серверів, кожен з яких виконує окремий набір сервісних функцій - наприклад, управління пам'яттю, створення або планування процесів. Кожен сервер виконується в призначеному для користувача режимі. Клієнт, яким може бути або інший компонент ОС, або прикладна програма, запрошує сервіс, посилаючи повідомлення на сервер. Ядро ОС (зване тут мікроядром), працюючи в привілейованому режимі, доставляє повідомлення потрібному серверу, сервер виконує операцію, після чого ядро повертає результати клієнтові за допомогою іншого повідомлення (малюнок 1.3).
ОС, що реалізовують модель клієнт-сервер, мають наступні особливості:
стандартизовані запити між клієнтом і сервером;
функції між клієнтом і сервером жорстко не закріплюються.
Мікроядерні операційні системи
Мікроядро - це мінімальна стрижньова частина операційної системи, Мабуть, більшість операційних систем наступного покоління володітимуть мікроядрами. Проте є маса різних думок з приводу того, як слід організовувати служби операційної системи по відношенню до мікроядра: як проектувати драйвери пристроїв, щоб добитися найбільшої ефективності, але зберегти функції драйверів максимально незалежними від апаратури; чи слід виконувати операції, що не відносяться до ядра, в просторі ядра або в просторі користувача; чи варто зберігати програми наявних підсистем (наприклад, Unix) або краще відкинути все і почати з нуля.
Поняття мікроядра ввела компанія Next, в операційній системі в якої використовувалося мікроядро Mach. Невелике привілейоване ядро цієї ОС, довкола якого розташовувалися підсистеми, що виконуються в режимі користувача, теоретично повинне було забезпечити небувалу гнучкість і модульність системи. Але на практиці ця перевага була дещо знецінена наявністю монолітного сервера, що реалізовує операційну систему UNIX BSD 4.3, яку компанія Next вибрала як оболонку мікроядра Mach. Проте опора на Mach дала можливість включити в систему засоби передачі повідомлень і ряд об'єктно-орієнтованих сервісних функцій, на основі яких удалося створити елегантний інтерфейс кінцевого користувача з графічними засобами конфігурації мережі, системного адміністрування і розробки програмного забезпечення.
Наступною мікроядерною операційною системою була Windows NT компанії Microsoft, в якій ключовою перевагою використання мікроядра повинні були стати не лише модульність, але і переносимість. ОС NT була побудована так, щоб її можна було застосовувати в одно- і мультипроцесорних системах, заснованих на процесорах Intel, Mips і Alpha (і тих, які прийдуть услід за ними). Оскільки в середовищі NT повинні були виконуватися програми, написані для DOS, Windows, OS/2 і систем, сумісних із стандартами Posix, компанія Microsoft використовувала властиву мікроядерному підходу модульність для створення загальної структури NT, що не повторює жодну з існуючих операційних систем. Кожна операційна система емулюється у вигляді окремого модуля або підсистеми.
Пізніше мікроядерна архітектура операційних систем була оголошена компаніями Novell/USL, Open Software Foundation (OSF), IBM, Apple і іншими. Одним з основних конкурентів NT в області мікроядерних ОС є Mach 3.0, система, створена в університеті Карнеги-Меллон, яку як IBM, так і OSF взялися довести до комерційного вигляду. Іншим конкурентом є мікроядро Chorus 3.0 компаній Chorus Systems, вибране USL як основа нових реалізацій ОС Unix. Деяке мікроядро використовуватиметься в SPRINGOS фірми Sun, об'єктно-орієнтованому наступнику ОС Solaris. Очевидна тенденція до переходу від монолітних до мікроядерних систем .(хоча, цей процес не є прямолінійним: компанія IBM зробила крок назад і відмовилася від переходу до мікроядерної технології). До речі, це зовсім не новина для компаній QNX Software Systems і Unisys, які вже протягом декількох років випускають мікроядерні операційні системи, що користуються успіхом. ОС QNX має попит на ринку систем реального часу, а CTOS фірми Unisys популярна в області банкової справи. У обох системах успішно використана модульність, властива мікроядерним ОС.
Функції мікроядра
Мікроядро реалізує базові функції операційної системи, на які спираються інші системні служби і додатки. Основною проблемою при конструюванні мікроядерної ОС є розпізнавання тих функцій системи, які можуть бути винесені з ядра. Такі важливі компоненти ОС як файлові системи, системи управління вікнами і служби безпеці стають периферійними модулями, що взаємодіють з ядром і один з одним.
Колись видавалося, що багаторівнева архітектура ядра ОС UNIX є вершиною в області конструювання операційних систем. Основні функціональні компоненти операційної системи - файлова система, взаємодія процесів (IPC - interprocess communications), уведення-виведення і управління пристроями - були розділені на рівні, кожен з яких міг взаємодіяти лише з рівнем, що безпосередньо примикає до нього.
Не дивлячись на непогані практичні результати така структура тепер все більше сприймається монолітною, оскільки вся операційна система зв'язана ієрархією рівнів. Множинність і нечіткість інтерфейсів між рівнями утрудняє модифікацію системи; для цього потрібне хороше знання операційної системи, маса часу і елемент везіння.
У мікроядерній архітектурі вертикальний розподіл функцій операційної системи замінюється на горизонтальний. Компоненти, лежачі вище мікроядра, використовують засоби мікроядра для обміну повідомленнями, але взаємодіють безпосередньо. Мікроядро лише перевіряє законність повідомлень, пересилає їх між компонентами і забезпечує доступ до апаратури.
Це властивість мікроядерних систем дозволяє природно використовувати їх в розподіленій середі. При здобутті повідомлення мікроядро може його обробити або переслати іншому процесу. Оскільки для мікроядра байдуже, чи вчинило повідомлення від локального або видаленого процесу, подібна схема передачі повідомлень є зручною основою видалених викликів процедур (RPC - remote procedure calls). Проте пересилка повідомлень проводиться повільнішим за звичайні виклики функцій; оптимізація пересилки повідомлень є критичним чинником успіху мікроядерної операційної системи. Наприклад, в ОС Windows NT в деяких випадках для оптимізації використовується пам'ять, що розділяється. Витрати на додаткову фіксовану пам'ять мікроядра виправдовуються підвищенням ефективності передачі повідомлень.
Основним принципом організації мікроядерних ОС є включення до складу мікроядра лише тих функцій, яким абсолютно необхідно виконувати в режимі супервізора і в захищеній пам'яті. Зазвичай в мікроядро включаються машинно-залежні програми (включаючи підтримку мультипроцесорної роботи), деякі функції управління процесами, обробка переривань і підтримка пересилки повідомлень.
У багатьох випадках в мікроядро включається функція планерування процесів, але в реалізації Mach компанії IBM планувальник процесів розміщений поза мікроядром, а мікроядро використовується лише для безпосереднього управління процесами. Звичайно, при цьому потрібна тісна взаємодія зовнішнього планувальника і вхідного до складу ядра диспетчера.
У деяких реалізаціях (наприклад, в реалізації OSF) в мікроядро поміщаються драйвери пристроїв. У реалізаціях IBM і Chorus драйвери розміщуються поза мікроядром, але для регулювання режимів дозволу і заборони переривань частина програми драйвера виконується в просторі ядра. У NT драйвери пристроїв і інші функції введення-виводу виконуються в просторі ядра, але реально використовують ядро лише для перехоплення і передачі переривань. Слід зауважити, що обидва підходи допускають динамічне підключення драйверів до системи і їх відключення.
Проте є інші аргументи на користь виділення драйверів із складу мікроядра. Наприклад, оскільки у багатьох випадках драйвери можуть не залежати від особливостей апаратури, такий підхід полегшує переносимість системи.
Нові мікроядерні системи
Операційна системи SPRINGOS фірми Sun, грунтується на мікроядрі і об'єктах. Ймовірно, в SPRINGOS використовуватиметься значний об'єм існуючих програм Solaris подібно до того, як в OSF/1 використовується існуючий сервер OSF/1. Компанія Sun не оголошувала про використання якого-небудь існуючого мікроядра і, мабуть використовує власну розробку.
Зрілі мікроядра
QNX і CTOS - це дві зрілі мікроядерні операційні системи, що поставляються впродовж декількох років. 8-кілобайтне мікроядро QNX підтримує лише планерування і диспетчеризацію процесів, взаємодію процесів, обробку переривань і мережні служби нижнього рівня. Це мікроядро забезпечує всього лише 14 системних викликів. Мікроядро QNX може бути цілком розміщено у внутрішньому кеші деяких процесорів, таких як Intel 486.
Щоб побудувати мінімальну систему QNX, потрібно додати до мікроядра менеджер процесів, який створює і управляє процесами і пам'яттю процесів. Щоб ОС QNX була застосовна не лише у вбудованих і бездисковых системах, потрібно додати файлову систему і менеджер пристроїв. Ці менеджери виконуються поза простором ядра, так що ядро залишається невеликим. По затвердженнях фахівців компанії QNX Software заявляє, що подібна система, заснована на передачі повідомлень, має продуктивність, щонайменше порівнянну з продуктивністю інших традиційних операційних систем.
CTOS, що з'явилася в 1980 році, була написана для робочих станцій фірми Convergent Technologies - сімейства машин на основі процесорів Intel для роботи в "кластерних мережах", сполучених по звичайних телефонних дротах. Що продаються в даний час фірмою Unisys, ці засновані на CTOS машини продемонстрували переваги розподілених обчислень на основі передачі повідомлень задовго до того, як цей термін став модним. Крихітне 4-кілобайтне мікроядро CTOS узяло на себе лише планерування і диспетчеризацію процесів і взаємодію процесів на основі повідомлень. Всі інші системні служби взаємодіють з ядром і один з одним через чітко певні інтерфейси повідомлень.
Мережні засоби входять до складу CTOS і є дійсно прозорими для прикладних програм, яким не потрібно знати, чи буде оброблений запит на обслуговування локальним або віддаленим. У будь-якому випадку повідомлення передає одна і та ж система взаємодії процесів.