Оболонка

Операційна система являє собою програму, що виконує системні виклики. Редактори, компілятори, асемблер, компонувальник і інтерпретатори команд за визначенням не є частиною операційної системи при всій своїй важливості і принесеної користі.________________________________________________________________________— shell.

__________________________________________________________________________________________________________________________________________________________________________________.

Коли не застосовується графічний користувальницький інтерфейс, вона також є основним інтерфейсом між користувачем, сидячим за своїм терміналом, і операційною системою. Існує безліч оболонок, включаючи sh, csh, ksh і bash. Всі вони підтримують розглянуті далі функції, що відбуваються з вихідної оболочка (sh).

3.3 Системні виклики

Системний виклик читання - read, ____________________________________________________________

_________________________________________________________________________________________.

Системний виклик (і бібліотечна процедура) _________________________________________________

_________________________________________________________________________________________

count. Зазвичай це значення співпадає зі значенням параметра nbytes, але може бути і менше, якщо, наприклад, у процесі читання буде досягнуто кінець файлу.

Виконання системного виклику складається з декількох кроків. Для прояснення ситуації повернемося до згадуваної вище прикладу виклику read. Спочатку, при підготовці виклику бібліотечної процедури read, яка фактично і здійснювала системний виклик read, зухвала програма поміщає параметри в стек, як показано на рис. 1.17 кроками 1-3.

Фактичний виклик бібліотечної процедури (крок 4). ___________________________________________ ______________________________________________________________________________________________.

Бібліотечна процедура, можливо написана на асемблері, зазвичай по - міщан номер системного виклику туди, де його чекає операційна система, наприклад в регістр (крок 5). Потім вона виконує команду TRAP для переключення з користувальницького режиму в режим ядра, і виконання триває з фіксованої адреси, що знаходиться усередині ядра операційної системи (крок 6).

Що почала роботу після команди TRAP частина ядра (диспетчер на рис. 1.17) перевіряє номер системного виклику, а потім передає управління потрібного обробника. __________________________________________

__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

У стандарті POSIX визначено більше 100 процедур, що забезпечують обіг до системних викликів. Деякі наи ¬ більш важливі з них і згруповані для зручності за категоріями перераховані в табл. 1.1. Далі ми коротко опишемо кожен виклик і його призначення.

Однак більшість процедур POSIX ______________________________________________________

________________________________________________________________________________________

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

Лекція № 4

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

Монолітні системи можуть мати деяку структуру. _______________________________________

Ця інструкція перемикає машину з користувальницького режиму в режим ядра і передає керування операційній системі (крок 6 на рис. 1.17). Потім операційна система витягує параметри і визначає, який системний виклик повинен бути виконаний. Після цього вона переміщається по індексу в таблиці, яка в рядку k містить покажчик на процедуру, що виконує системний виклик k (крок 7 на рис. 1.17).

Така організація _______________________________________________________________________

1. ______________________________________________________________________________________

2. _______________________________________________________________________________________

3. ______________________________________________________________________________________

Процедури діляться на три рівні, які показані на рис. 1.21.

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

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

Узагальненням підходу, показаного на рис. 1.21, є організація операцион ної системи у вигляді ієрархії рівнів, кожен з яких є надбудовою над нижележащим рівнем. Першою системою, побудованої таким чином, була система ТНЕ, створена в Technische Hogeschool Eindhoven в Голландії Е. Дейк-лад (Є. W. Dijkstra) і його студентами у 1968 році. Система ТНЕ була простою пакетной системою для голландського комп'ютера Electrologica Х8, що мав пам'ять 32 До 27-розрядних слів. Як показано в табл. 1.3, у системи було шість рівнів. Рівень 0 займався розподілом ресурсу процесора (процесорного часу), перемиканням між процесами при виникненні переривань або закінчення часу таймера.

Рівень 1 управляв пам'яттю.______________________________________________________________

__________________________________________________________________________________________________________________________________________________________________________________________

Рівень 2 управляв зв'язком кожного процесу з консоллю оператора (тобто з користувачем). ______

________________________________________________________________________________________

Рівень 3 управляв пристроями вводу-виводу і буферизацією інформаційних потоків в обох напрямках. ________________________________________________________________________________

________________________________________________________________________________________

На рівні 4 працювали користувальницькі програми,___________________________________________

________________________________________________________________________________________

Процес системного оператора розміщувався на рівні 5.

4.3 Мікроядра

Задум, покладений в основу конструкції мікроядра, спрямований ______________________________

Зокрема, якщо запустити кожен драйвер пристрою і файлову систему як окремі користувацькі процеси, то помилка в одному з них може викликати відмову відповідного компонента, але не зможе викликати збій всієї системи

Мікроядро MINIX 3, в якому максимально використана ідея модульності і основна частина операційної системи розбита на ряд незаежних процесів, що працюють в режимі користувача.

Структура процесу MINIX 3 показана на рис. 1.22.

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

За межами ядра структура системи являє собою три рівні процессов, які працюють в режимі користувача.

Окремий інтерес представляє служба перевтілення (reincarnation server),____________________ ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Лекція № 5

5.1 Клієнт-серверна модель

Невелика варіація ідеї мікроядер виражається у відокремленні двох класів процесів:

- ______________________________________________________________________________________

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

Зв'язок між клієнтами і серверами часто організовується за допомогою передачі со - спілкувань. Щоб скористатися службою, клієнтський процес становить повідомлення, в якому говориться, що саме йому потрібно, і відправляє його відповідній службі. Потім служба виконує певну роботу і відправляє назад відповідь. Якщо клієнт і сервер запущені на одній і тій же машині, то можна провести визначену оптимізацію, але концептуально тут йде мова про передачу повідомлень.

Очевидним розвитком цієї ідеї буде запуск клієнтів і серверів на різних комп'ютерах, з'єднаних локальною або глобальною мережею, як показано на рис. 1.23. Оскільки клієнти зв'язуються з серверами шляхом відправки повідомлень, їм не обов'язково знати, чи будуть ці повідомлення оброблені локально, на їх соб ¬ дарських машинах, або ж вони будуть відправлені по мережі на сервери, розташований ні на віддалених машинах. Що стосується інтересів клієнта, слід зазначити, що в обох випадках відбувається одне й те ж: відправляються запити і повертаються відповіді. Таким чином, клієнт-серверна модель є __________________________________________________________________________________________________________________________________________________________________________________

Машина 1 Машина 2 Машина 3 Машина 4

Повідомлення від клієнта сервера Рис. 1.23. Клієнт-серверна модель, реалізована за допомогою мережі

5.2 Віртуальні машини

5.2.1 VM/370

Група з наукового центру IBM Scientific Center в Кембриджі, Массачусетс, раз - працювала зовсім іншу систему, яку IBM в кінцевому підсумку прийняла як закінчений продукт. Ця система, спочатку називалася CP / CMS, а пізніше перейменована в VM/370 (Seawright and MacKinnon, 1979), була осно - вана на наступному проникливому спостереженні: система з поділом часу забезпечує:

1) _____________________________________________________________________________________

2) _____________________________________________________________________________________

Сутність VM/370 полягає в повному поділі цих двох функцій.

Основа системи, відома як монітор віртуальних машин, запускається безпосередньо на звичайному обладнанні та забезпечує багатозадачність, передіставлення верхньому рівню не одну, а кілька віртуальних машин (рис. 1.24).

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

5.2.2 Віртуальна машина Java

Віртуальні машини використовуються - правда, дещо в інший спосіб - і в іншій області: для запуску програм на мові Java. Коли компанія Sun Microsystems винайшла мову програмування Java, вона також винайшла і віртуальну машину (тобто архітектуру комп'ютера), названу JVM (Java Virtual Machine - віртуальний машина Java). Компілятор Java створює код для JVM, який потім зазвичай виконується програмним інтерпретатором JVM.