Екзоядро

В системі VM/370 кожен користувач отримує точну копію цієї ма-

машини. На Pentium, в режимі віртуальної машини 8086, кожен користувач

отримує точну копію іншої машини. Розгорнувши цю ідею далі, дослідники

з Массачусетського технологічного інституту винайшли систему, яка забезпечує кожного користувача абсолютною копією реального комп'ютера, але з підмножи-ною ресурсів [111]. Наприклад, одна віртуальна машина може отримати

блоки на диску з номерами від 0 до 1023, наступна - від 1024 до 2047 і т. д.

На нижньому рівні в режимі ядра працює програма, яка називається екзоядро (exokernel). У її завдання входить розподіл ресурсів для віртуальних машин, а після цього перевірка їх використання (тобто відстеження спроб машин використовувати чужий ресурс). Кожна віртуальна машина на рівні користувача може працювати з власною операційною системою, як на VM/370 або віртуаль-них 8086-х для Pentium, з тією різницею, що кожна машина обмежена

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

Модель клієнт-сервер

Система VM/370 сильно виграє в простоті завдяки перенесенню значною

значної частини коду традиційної операційної системи (забезпечує розширену машину) у верхній рівень, систему CMS. Однак VM/370 і при цьому залишиться складною комплексною програмою, тому що моделювання декількох віртуаль-них 370-х машин саме по собі не так просто (особливо якщо ви хочете зробити це досить ефективно). У розвитку сучасних операційних систем спостерігається тенденція в стобік подальшого перенесення коду в верхні рівні і видаленні при цьому все, що тільки можливо, з режиму ядра, залишаючи мінімальне мікроядро. Зазвичай це здійснюється перекладанням виконання більшості завдань операцій-ної системи на кошти користувацьких процесів. Отримуючи запит на будь-яку операцію, наприклад читання блоку файлу, користувальницький процес (тепер називаються

званий обслуговується процесом чи процесом клієнтським) надсилає запит

серверному (обслуговуючому) процесу, який його обробляє і висилає

тому відповідь.У моделі, показаної на рис. 1.23, У завдання ядра входить лише управління зв'язком між клієнтами та серверами. Завдяки розподілу операційної

системи на частини, кожна з яких управляє лише одним елементом системи

(Файловою системою, процесами, терміналом або пам'яттю), всі частини стають

маленькими і керованими. До того ж, оскільки всі сервери працюють як процеси в режимі користувача, а не в режимі ядра, вони не мають прямого доступу до обладнання. Тому якщо відбувається помилка на файловому сервері,

може зруйнуватися служба обробки файлових запитів, але це зазвичай не

призводить до зупинки всієї машини цілком.

Рис. 1.23. Модель клієнт-сервер

Інша перевага моделі клієнт-сервер полягає в її простій адаптації до використання в розподілених системах (рис. 1.24). Якщо клієнт спілкується з сервером, посилаючи йому повідомлення, клієнтові не потрібно знати обробляє-ться. Чи його повідомлення локально на його власній машині або воно було надіслано на мережі серверу на віддаленій машині. З точки зору клієнта відбувається одне й те ж в обох випадках: запит був посланий, і на нього отримана відповідь. Розказана вище історія про ядро, що управляє передачею повідомлень від клієнтів до серверів і тому, не зовсім реалістична. Деякі функції операційної системи, такі як завантаження команд в регістри фізичних пристроїв введення-виводу, важко, якщо взагалі можливо, виконати з програм в просторі

користувача. Є два способи вирішення цієї проблеми. Перший полягає

в тому, що деякі критичні серверні процеси (наприклад, драйвери пристроїв введення-виведення) дійсно запускаються в режимі ядра, з повним доступом до апаратури, але при цьому спілкуються з іншими процесами за допомогою

звичайної схеми передачі повідомлень.

Другий спосіб полягає в тому, щоб вбудувати мінімальний механізм обробки інформації в ядро, але залишити прийняття політичних рішень за серверами в просторі користувача [202]. Наприклад, ядро ​​може впізнавати повідомлення, послані за певними адресами. Для ядра це означає, що потрібно взяти вміст повідомлення і завантажити його, скажімо, в регістри введення виведення деякого диска для запуску операції читання диска. У цьому прикладі ядро ​​навіть може не обстежити байти повідомлення, якщо вони виявилися припустимі або осмислені, воно може наосліп копіювати їх у регістри диска. (Очевидно, повинна використо-вуватися деяка схема, що обмежує коло процесів, що мають право відправляти подібні повідомлення.) Розділення між механізмом та політикою є дуже важливим поняттям, яке трапляється в операційних системах в різному контексті постійно.

Рис. 1.24. Модель клієнт-сервер в розподіленій системі