
- •Поняття операційної системи
- •Операційна система як розширена машина
- •Операційна система як менеджер ресурсів
- •Історія розвитку операційних систем
- •Перше покоління (1945-1955): електронні лампи і комутаційні панелі
- •Друге покоління (1955-1965): транзистори і системи пакетної обробки
- •Третє покоління (1965-1980): інтегральні схеми і багатозадачність
- •Четверте покоління (з 1980 року по наші дні): персональні комп'ютери
- •Історія minix 3
- •Основні концепції
- •Процеси
- •Оболонка
- •Системні виклики
- •Системні виклики для управління процесами
- •Системні виклики для управління сигналами
- •Системні виклики для управління файлами
- •Системні виклики для управління каталогами
- •Системні виклики для захисту
- •Системні виклики для управління часом
- •Структура операційної системи
- •1.5.2. Багаторівневі системи
- •1.5.3. Віртуальні машини
- •1.5.4. Екзоядра
- •1.5.5. Модель клієнт-сервер
- •2.1.1. Модель процесів
- •2.1.2. Створення процесів
- •2.1.3. Завершення процесів
- •2.1.4. Ієрархії процесів
- •2.1.5. Стани процесів
- •2.1.6. Реалізація процесів
- •2.1.7. Програмні потоки
- •2.2. Взаємодія між процесами
- •5.1. Файли
- •5.1.1. Іменування файлів
- •5.1.2. Структура файлу
- •5.1.3. Типи файлів
- •5.1.4. Доступ до файлів
- •5.1.5. Атрибути файлів
- •5.1.6. Операції з файлами
- •5.2. Каталоги
- •5.2.1. Прості каталоги
- •5.2.2. Ієрархічні системи каталогів
- •5.2.3. Шляхи
- •5.2.4. Операції з каталогами
- •5.3. Реалізація файлової системи
- •5.3.1. Структура файлової системи
- •5.3.2. Реалізація файлів
- •5.3.4. Організація дискового простору
1.5.4. Екзоядра
В системі VM/370 кожен процес користувача отримує точну копію
цієї машини. На Pentium, в режимі віртуальної машини 8086, кожен
користувальницький процес отримує точну копію іншої машини. Ступивши трохи
далі, дослідники з Массачусетського технологічного інституту
винайшли систему, яка забезпечує кожного користувача абсолютною копією
реального комп'ютера, але зі своїм підмножиною ресурсів . Наприклад,
одна віртуальна машина може отримати блоки на диску з номерами від 0 до
1023, наступна - від 1024 до 2047 і т. д. На нижньому рівні в режимі ядра працює програма, яка називається екзоядро (exokernel). В її завдання входить розподіл ресурсів для віртуальних машин, а після цього перевірка їх використання (тобто відстеження спроб
машин задіяти чужий ресурс). Кожна віртуальна машина на рівні користувача може працювати з власною операційною системою, як на VM/370 або віртуальних машинах 8086 для Pentium, з тією різницею, що кожна машина обмежена набором ресурсів, які вона запросила і які їй були надані.
Перевага схеми екзоядра полягає в тому, що вона дозволяє обійтися
без рівня відображення. При інших методах роботи кожна віртуальна
машина вважає, що вона використовує власний диск з нумерацією блоків від 0 до
деякого максимуму. Тому монітор віртуальної машини повинен
підтримувати таблиці перетворення адрес на диску (і всіх інших ресурсів).
Необхідність перетворення відпадає при наявності екзоядра, якому потрібно
тільки зберігати запис про те, який віртуальній машині виділений даний
ресурс. Подібний підхід має ще одну перевагу: він відокремлює
багатозадачність (в екзоядрі) від операційної системи користувача (в призначеному для користувача
просторі) з меншими витратами, тому що для цього йому необхідно всього
лише не допускати втручання однієї віртуальної машини в роботу іншої.
1.5.5. Модель клієнт-сервер
Система VM/370 сильно виграє в простоті завдяки перенесенню значної частини коду (що забезпечує розширену машину) традиційної операційної системи на верхній рівень, в систему CMS. Однак VM/370 і при цьому залишиться складною комплексною програмою, тому що моделювання декількох віртуальних машин 370 само по собі не так просто (особливо якщови хочете зробити це досить ефективно).
У розвитку сучасних операційних систем спостерігається тенденція в
сторону подальшого перенесення коду на верхні рівні і видаленні при цьому все, що
тільки можливо, з операційної системи, залишаючи мінімальне ядро.
Зазвичай для цього рішення більшості завдань операційної системи перекладається на призначені для користувача процеси. Отримуючи запит на обслуговування, наприклад
читання блоку файлу, користувальницький процес (тепер званий клієнтським) надсилає запит серверному процесу, який його обробляє і висилає назад відповідь.
У деякій моделі, в завдання ядра входить лише управління взаємодією між клієнтами і серверами. Завдяки розділенню операційної системи на частини, кожна з яких управляє лише одним елементом системи (файлової підсистемою, процесами, терміналом або пам'яттю), все частини стають невеликими і легко керованими. До того ж, оскільки всі
сервери працюють як процеси в режимі користувача, а не в режимі ядра, вони не мають прямого доступу до обладнання. Тому якщо відбувається помилка на файловому сервері, може виявитися непрацездатною служба обробки файлових запитів, але це зазвичай не призводить до зупинки машини в цілому.
Інша перевага моделі клієнт-сервер полягає в її простий адаптації до використання в розподілених системах Якщо клієнт спілкується з сервером, посилаючи йому повідомлення, клієнтові не потрібно знати, обробляється його повідомлення локально на його власній машині або воно надсилається мережі серверу на віддаленій машині. З точки зору клієнта в обох випадках відбувається одне й те саме: запит надсилається і на нього приходить відповідь.
Розказана історія про ядро, що управляє передачею повідомлень від клієнтів
до серверів і назад, не зовсім реалістична. Деякі функції операційної
системи, такі як завантаження команд в регістри фізичних пристроїв
введення-виведення, важко, якщо взагалі можливо, виконати з програм в
просторі користувача. Є два способи вирішення цієї проблеми. Перший
полягає в тому, що деякі критично важливі серверні процеси (наприклад,
драйвери пристроїв введення-виведення) дійсно запускаються в режимі ядра
з повним доступом до апаратури, але при цьому взаємодіють з іншими
процесами за звичайною схемою передачі повідомлень. Варіант такого механізму
використовувався в попередніх версіях MINIX, де драйвери компілювалися в ядро,
однак виконувалися як окремі процеси.
Другий спосіб полягає в тому, щоб вбудувати мінімальний механізм обробки
інформації в ядро, але залишити прийняття політичних рішень за серверами
в просторі користувача. Наприклад, ядро може впізнавати повідомлення,
послані за певними адресами. Для ядра це означає, що потрібно взяти з-
вміст повідомлення і завантажити його, скажімо, в регістри вводу-виводу
деякого диска для запуску операції читання диска. У цьому прикладі ядро навіть може
не обстежувати байти повідомлення, якщо вони виявилися допустимі або
осмислені, воно може наосліп копіювати їх у регістри диска. (Очевидно, повинна
використовуватися деяка схема, що обмежує коло процесів, що мають право
відправляти подібні повідомлення.) Саме так працює операційна система
MINIX 3. Драйвери знаходяться в просторі користувача і посилають
ядру спеціальні виклики, що запитують читання і запис регістрів
вводу-виводу або доступ до інформації, що міститься в ядрі. Поділ між
механізмом і політикою є дуже важливою концепцією, постійно використовуваної
в різних контекстах в операційних системах.
.
Резюме
Операційну систему можна розглядати з двох точок зору: як менеджер
ресурсів і як розширену машину. Як менеджер ресурсів операційна
система раціонально управляє різними частинами системи. З точки зору
розширеної машини, робота операційної системи полягає в наданні
користувачам віртуальної машини, більш зручною, ніж справжній комп'ютер.
Операційні системи мають досить довгу історію розвитку, яка починається з тих днів, коли операційні системи замінили оператора, і триває до сучасних багатозадачних систем.
Серцем будь-якої операційної системи є набір системних викликів, які вона може обробити. Вони говорять про те, що реально робить операційна система. Ми розглянули шість груп системних викликів для MINIX 3. Перша група забезпечує створення і завершення процесів. Друга група призначена для роботи з сигналами. Третя - для читання і запису файлів. Четверта потрібна для управління каталогами. П'ята включила в себе управління захистом, а шоста - управління часом.
Операційні системи можуть бути структуровані по-різному. У найбільш загальному випадку структурування може бути таким: монолітні системи, ієрархічні багаторівневі системи, віртуальні машини, екзоядра, модель клієнт-сервер.
Розділ 2
Процеси
З цього розділу ми почнемо детальне вивчення будови і роботи
операційних систем, в основному MINIX 3. Основною концепцією для будь
операційної системи є процес - абстракція запущеної програми.
Все інше базується на концепції процесу, тому представляється вкрай важливим, щоб розробники операційних систем (а також студенти) добре зрозуміли цю концепцію.
Всі сучасні комп'ютери можуть одночасно робити кілька речей. Наприклад, паралельно із запущеною користувачем програмою може виконуватися читання з диска і виведення тексту на екран монітора або на принтер. В багатозадачній системі процесор перемикається між програмами, надаючи кожній від десятків до сотень мілісекунд персонального часу. При цьому в кожен конкретний момент часу процесор зайнятий тільки однією програмою, але за секунду він встигає попрацювати з кількома, створюючи у користувачів ілюзію одночасної роботи з усіма програмами. Іноді в цьому контексті
говорять про псевдопараллелізм, на відміну від справжнього паралелізму в
багатопроцесорних системах (в яких встановлено два і більше процесора,
мають загальну фізичну пам'ять). Відслідковувати роботу паралельно протікають
процесів досить важко, тому з часом розробники операційних
систем придумали концептуальну модель логічно упорядкованих процесів.
У цьому розділі ми опишемо застосування цієї моделі, а також деякі
результати її використання.