Взаємодія ос і виконуваного програмного коду

У роботі в режимі користувача часто необхідне виконання дій, реалізованих у яд рі ОС (наприклад, під час запису на диск із прикладної програми). Для цього тре ба забезпечити взаємодію коду режиму користувача та ОС. Розглянемо особли вості такої взаємодії. 2.3. Операційна система та її оточення 33 Системні виклики та інтерфейс програмування застосувань Системний виклик — це засіб доступу до певної функції ядра операційної системи із прикладних програм. Набір системних викликів визначає дії, які ядро може ви конати за запитом процесів користувача. Системні виклики задають інтерфейс між прикладною програмою і ядром ОС. Розглянемо послідовність виконання системного виклику. 1. Припустимо, що для процесу, який виконується в режимі користувача, потрібна функція, реалізована в ядрі системи. 2. Для того щоб звернутися до цієї функції, процес має передати керування ядру ОС, для чого необхідно задати параметри виклику і виконати програмне пере ривання (інструкцію системного виклику). Відбувається перехід у привілейо ваний режим. 3. Після отримання керування ядро зчитує параметри виклику і визначає, що потрібно зробити. 4. Після цього ядро виконує потрібні дії, зберігає в пам'яті значення, які слід по вернути, і передає керування програмі, що його викликала. Відбувається пе рехід назад у режим користувача. 5. Програма зчитує з пам'яті повернені значення і продовжує свою роботу. Як бачимо, кожний системний виклик спричиняє перехід у привілейований режим і назад (у мікроядровій архітектурі, як було зазначено вище, таких перехо дів може бути і більше). Розглянемо способи передачі параметрів у системний виклик. До них належать: • передача параметрів у регістрах процесора; • занесення параметрів у певну ділянку пам'яті й передача покажчика на неї в регістрі процесора. Системні виклики призначені для безпосереднього доступу до служб ядра ОС. На практиці вони не вичерпують (а іноді й не визначають) ті функції, які можна використати у прикладних програмах для доступу до служб ОС або засобів си стемних бібліотек. Для позначення цього набору функцій використовують термін інтерфейс програмування застосувань (Application Programming Interface, API). Взаємозв'язок між функціями АРІ і системними викликами неоднаковий у різних ОС. По-перше, кожному системному виклику може бути поставлена у відповід ність бібліотечна функція, єдиним завданням якої є виконання цього виклику. Таку функцію називають пакувальником системного виклику (system call wrapper). Для програміста в цьому разі набір функцій АРІ виглядає як сукупність таких па кувальників і додаткових функцій, реалізованих бібліотеками повністю або част ково в режимі користувача. Це рішення прийняте за основу в UNIX; у такому разі прийнято говорити про використання системних викликів у прикладних програ мах (насправді у програмах викликають пакувальники системних викликів). По-друге, можна надати для використання у прикладних програмах універ сальний інтерфейс програмування застосувань (АРІ режиму користувача) і пов ністю сховати за ним набір системних викликів. Для програміста кожна функція такого АРІ є бібліотечною функцією режиму користувача, пакувальника в цьому Архітектура операційних систем разі немає, відомості про системні виклики є деталями реалізації ОС. Це вла стиве Windows-системам, де подібний універсальний набір функцій називають Win32 АРІ Програмна сумісність Дотепер ми розглядали виконання в ОС програм, розроблених спеціально для неї. Іноді буває необхідно виконати в середовищі ОС програми, розроблені для інших ОС і, можливо, для іншої апаратної архітектури. У цьому разі виникає проблема програмної сумісності. Програмна сумісність означає можливість виконувати в середовищі однієї опе раційної системи програми, розроблені для іншої ОС. Розрізняють сумісність на рівні вихідних текстів (можливість перенесення вихідних текстів) та бінарну су місність (можливість перенесення виконуваного коду). Для сумісності на рівні вихідних текстів необхідно, щоб для всіх ОС існувала реалізація компілятора мови і АРІ, що його використовує програма. Сьогодні таку сумісність забезпечує стандартизація розробки програмного за безпечення, а саме: • наявність стандарту на мови програмування (насамперед на С і C++) і стан дартних компіляторів; • наявність стандарту на інтерфейс операційної системи (АРІ). Робота зі стандартизації інтерфейсу операційних систем відбувається у рам ках проекту POSIX (Portable Operating System Interface). Найбільш важливим стандартом є POSIX 1003.1 [3], який описує набір бібліотечних процедур (таких, як відкриття файла, створення нового процесу тощо), котрі мають бути реалізовані в системі. Цей процес стандартизації триває дотепер, останньою редакцією стан дарту є базова специфікація Open Group/IEEE [103]. Зазначені стандарти ві дображають традиційний набір засобів, реалізованих в UNIX-сумісних системах. Завдання забезпечення бінарної сумісності виникає тоді, коли потрібно за пустити на виконання файл прикладної програми у середовищі іншої операцій ної системи. Таке завдання значно складніше в реалізації, найпоширеніший під хід до його розв'язання — емуляція середовища виконання. У цьому разі програма запускається під керуванням іншої програми — емулятора, який забезпечує ди намічне перетворення інструкцій програми в інструкції потрібної архітектури. Прикладом такого емулятора є програма wine, яка дає можливість запускати про грами, розроблені для Win32 АРІ, у середовищі Linux через емуляцію функцій Win32 АРІ системними викликами Linux.

Особливості архітектури: UNIX і Linux

Базова архітектура UNIX

UNIX є прикладом досить простої архітектури ОС. Більша частина функціональ ності цієї системи міститься в ядрі, ядро спілкується із прикладними програмами за допомогою системних викликів. Базова структура класичного ядра UNIX зобра жена на рис. 2.3 (див., наприклад, [33, 59]). 2.4. Особливості архітектури: UNIX і Linux 35 Система складається із трьох основних компонентів: підсистеми керування процесами, файлової підсистеми та підсистеми введення-виведення. Підсистема керування процесами контролює створення та вилучення проце сів, розподілення системних ресурсів між ними, міжпроцесову взаємодію, керу вання пам'яттю. Файлова підсистема забезпечує єдиний інтерфейс доступу до даних, розташо ваних на дискових накопичувачах, і до периферійних пристроїв. Такий інтерфейс є однією з найважливіших особливостей UNIX. Одні й ті самі системні виклики використовують як для обміну даними із диском, так і для виведення на термінал або принтер (програма працює із принтером так само, як із файлом). При цьому файлова система переадресовує запити відповідним модулям підсистеми введен ня-виведення, а ті - безпосередньо периферійним пристроям. Крім того, файлова підсистема контролює права доступу до файлів, які значною мірою визначають привілеї користувача в системі. Підсистема введення-виведення виконує запити файлової підсистеми, взаємо діючи з драйверами пристроїв. В UNIX розрізняють два типи пристроїв: сим вольні (наприклад, принтер) і блокові (наприклад, жорсткий диск). Основна відмінність між ними полягає в тому, що блоковий пристрій допускає прямий 36 Розділ 2. Архітектура операційних систем доступ. Для підвищення продуктивності роботи із блоковими пристроями вико ристовують буферний кеш — ділянку пам'яті, у якій зберігаються дані, зчитані з диска останніми. Під час наступних звертань до цих даних вони можуть бути от римані з кеша. Сучасні UNIX-системи дещо відрізняються за своєю архітектурою. • У них виділено окремий менеджер пам'яті, відповідальний за підтримку вір туальної пам'яті. • Стандартом для реалізації інтерфейсу файлової системи є віртуальна файло ва система, що абстрагує цей інтерфейс і дає змогу організувати підтримку різних типів файлових систем. • У цих системах підтримується багатопроцесорна обробка, а також багатопото ковість. Базові архітектурні рішення, такі як доступ до всіх пристроїв введення-виве дення через інтерфейс файлової системи або організація системних викликів, за лишаються незмінними в усіх реалізаціях UNIX.