АРХІТЕКТУРА ОПЕРАЦІЙНИХ СИСТЕМ (курсова робота)

Зміст

Вступ    3

Ядро і допоміжні модулі ОС    4

Ядро в привілейованому режимі    7

Багаторівнева структура ОС    12

Апаратна незалежність і здатність до перенесення ОС    18

Типові засоби апаратної підтримки ОС    18

Машинно-залежні компоненти ОС    22

Здатність операційної системи до перенесення    24

Мікроядерна архітектура    27

Переваги і недоліки мікроядерної архітектури    29

Сумісність і множинні прикладні середовища    33

Бінарна сумісність і сумісність вихідних текстів    33

Трансляція бібліотек    35

Способи реалізації прикладних програмних середовищ    36

Висновок    42

Список використаної літератури    44

 

 

 

 

Вступ

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

Функціональна складність операційної системи неминуче приводить до складності її архітектури, під якою розуміють структурну організацію ОС на основі різних програмних модулів. Зазвичай до складу ОС входять виконувані і об’єктні модулі стандартних для даної ОС форматів, бібліотеки різних типів, модулі початкового тексту програм, програмні модулі спеціального формату (наприклад, завантажувач ОС, драйвери введення-виведення), конфігураційні файли, файли документації, модулі довідкової системи і т.д.

Більшість сучасних операційних систем є добре структуровані модульні системи, здатні до розвитку, розширення і перенесення на нові платформи. Якої-небудь єдиної архітектури ОС не існує, але існують універсальні підходи до структуризації ОС.

 

Ядро і допоміжні модулі ОС

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

  • ядро — модулі, що виконують основні функції ОС;
  • модулі, що виконують допоміжні функції ОС.

Модулі ядра виконують такі базові функції ОС, як управління процесами, пам’яттю, пристроями введення-виведення і т.п. Ядро складає серцевину
операційної системи, без нього ОС є повністю непрацездатною і не зможе виконати жодну з своїх функцій.

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

Функції, що виконуються модулями ядра, є найбільш часто використовуваними функціями операційної системи, тому швидкість їх виконання визначає продуктивність всієї системи в цілому. Для забезпечення високої швидкості роботи ОС всі модулі ядра або більша їх частина постійно знаходяться в оперативній пам’яті, тобто є резидентними.

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

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

Решту модулів ОС виконують важливі, але менш обов’язкові функції. Наприклад, до таких допоміжних модулів можуть бути віднесені програми архівації даних на магнітній стрічці, дефрагментації диска, текстовий редактор. Допоміжні модулі ОС оформлюються або у вигляді прикладних програм, або у вигляді бібліотек процедур.

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

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

Деяке застосування може існувати певний час як призначена для користувача прикладна програма, а потім стати частиною ОС, або навпаки. Яскравим прикладом такої зміни статусу програми є Web-браузер компанії Microsoft, який спочатку поставлявся як окрема прикладна програма, потім став частиною операційних систем Windows NT 4.0 і Windows 95/98, а сьогодні існує велика вірогідність того, що за рішенням суду цей браузер знову перетвориться на самостійну програму.

Допоміжні модулі ОС зазвичай розділяються на наступні групи:

  • утиліти — програми, які вирішують окремі завдання управління і супроводу комп’ютерної системи, наприклад, такі як програми стиснення дисків, архівації даних на магнітну стрічку;
  • системні оброблювальні програми — текстові або графічні редактори, компілятори, компонувальники, відладчики;
  • програми надання користувачеві додаткових послуг — спеціальний варіант призначеного для користувача інтерфейсу, калькулятор і навіть ігри;
  • бібліотеки процедур різного призначення, що спрощують розробку прикладних програм, наприклад бібліотека математичних функцій, функцій введення-виведення і т.д.

Як і звичайні прикладні програми, для виконання своїх завдань утиліти, оброблювальні програми і бібліотеки ОС, звертаються до функцій ядра за допомогою системних викликів (рис. 1).

Розділення операційної системи на ядро і модулі-програми забезпечує легку розширюваність ОС. Щоб додати нову високорівневу функцію, досить розробити нову прикладну програму, і при цьому не потрібно модифікувати відповідні функції, створюючи ядро системи. Проте внесення змін у функції ядра може бути набагато складніше, і складність ця залежить від структурної організації самого ядра. В деяких випадках кожне виправлення в ядрі може вимагати його повної перекомпіляції.


Рис. 1. Взаємодія між ядром і допоміжними модулями ОС

Модулі ОС, оформлені у вигляді утиліт, системних оброблювальних програм і бібліотек, зазвичай завантажуються в оперативну пам’ять тільки на час виконання своїх функцій, тобто є транзитними. Постійно в оперативній пам’яті розміщуються тільки найнеобхідніші коди ОС, складові її ядра. Така організація економить оперативну пам’ять комп’ютера.

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

Ядро в привілейованому режимі

Для надійного управління ходом виконання програм операційна система повинна мати по відношенню до них певні привілеї. Інакше некоректно працююча програма може втрутитися в роботу ОС і, наприклад, зруйнувати частину її кодів. Всі зусилля розробників операційної системи виявляться марними, якщо їх рішення втілені в незахищені від прикладних програм модулі системи, якими б елегантними і ефективними ці рішення не були. Операційна система повинна володіти винятковими повноваженнями також для того, щоб грати роль арбітра в спорі прикладних програм за ресурси комп’ютера в мультипрограмному режимі. Жодна програма не повинна мати можливості, без відома ОС, отримувати додаткову область пам’яті, займати процесор довше дозволеного операційною системою періоду часу, безпосередньо управляти спільно використовуваними зовнішніми пристроями.

Забезпечити привілеї операційній системі неможливо без спеціальних засобів апаратної підтримки. Апаратура комп’ютера повинна підтримувати як мінімум два режими роботи — призначений для користувача (user mode) і привілейований режим, який також називають режимом ядра {kernel mode), або режимом супервізора (supervisor mode). Мається на увазі, що операційна система або деякі її частини працюють в привілейованому режимі, а прикладні програми — в режимі призначеному для користувача.

Оскільки ядро виконує всі основні функції ОС, то найчастіше саме ядро є тією частиною ОС, яка працює в привілейованому режимі (рис. 2). Іноді ця властивість — робота в привілейованому режимі — і є основним визначенням поняття «ядро».


Рис. 2. Архітектура операційної системи з ядром в привілейованому режимі

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

Аналогічно забезпечуються привілеї ОС при доступі до пам’яті. Наприклад, виконання інструкції доступу до пам’яті для прикладної програми дозволяється, якщо інструкція звертається до області пам’яті, відведеної даній програмі операційною системою, і забороняється при зверненні до областей пам’яті, зайнятих ОС або іншими прикладними програмами. Повний контроль ОС над
доступом до пам’яті досягається за рахунок того, що інструкція або інструкції конфігурації механізмів захисту пам’яті (наприклад, зміни ключів захисту пам’яті в мейнфреймах IBM або покажчика таблиці дескрипторів пам’яті в процесорах Pentium) дозволяється виконувати тільки в привілейованому режимі.

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

Між кількістю рівнів привілеїв, реалізованих апаратно, і кількістю рівнів привілеїв, підтримуваних ОС, немає прямої відповідності. Так, на базі чотирьох рівнів, що забезпечуються процесорами компанії Intel, операційна система OS/2 будує трьохрівневу систему привілеїв, а операційні системи Windows NT, UNIX і деякі інші обмежуються дворівневою системою.

З іншого боку, якщо апаратура підтримує хоч би два рівні привілеїв, то на цій основі програмно ОС може створити яку завгодно розвинену систему захисту.

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

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

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


Рис. 3. Зміна режимів при виконанні системного виклику до привілейованого ядра

Архітектура ОС, розроблена на привілейованому ядрі і прикладних програмах для режиму користувача, по суті, стала класичною. Її використовують багато популярних операційних систем, зокрема багато версій UNIX,VAX VMS, IBM OS/390, OS/2, і з певними модифікаціями — Windows NT.

В деяких випадках розробники ОС відступають від цього класичного варіанту архітектури, організовуючи роботу ядра і прикладних програм в одному і тому ж режимі. Так, відома спеціалізована операційна система NetWare компанії Novell використовує привілейований режим процесорів Intel x86/ Pentium як для роботи ядра, так і для роботи своїх специфічних програм — завантажуваних модулів NLM. При такій побудові ОС звернення прикладних програм до ядра виконуються швидше, оскільки немає перемикання режимів, проте при цьому відсутній надійний апаратний захист пам’яті, зайнятої модулями ОС, від некоректно працюючої програми. Розробники NetWare пішли на таке потенційне зниження надійності своєї операційної системи, оскільки обмежений набір її спеціалізованих програм дозволяє компенсувати цей архітектурний недолік за рахунок ретельного налагодження кожної прикладної програми.

У одному режимі працюють також ядро і прикладні програми тих операційних систем, які розроблені для процесорів, що взагалі не підтримують привілейованого режиму роботи. Найбільш популярним процесором такого типу був процесор Intel 8088/86, що послужив основою для персональних комп’ютерів компанії IBM. Операційна система MS-DOS, розроблена компанією Microsoft для цих комп’ютерів, складалася з двох модулів msdos.sys і io.sys, що складали ядро системи (хоча назва «ядро» для цих модулів не уживалася, за своєю суттю вони ними і були), до яких з системними викликами зверталися командний інтерпретатор command.com, системні утиліти і прикладні програми. Некоректно написані програми цілком могли пошкодити основні модулі MS-DOS, що іноді і відбувалося, але область використання MS-DOS (і багато подібних до неї ранніх операційних систем для персональних комп’ютерів, таких як MSX, СР/М) і не висувала високих вимог до надійності ОС.

Багаторівнева структура ОС

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

Багаторівневий підхід є універсальним і ефективним способом декомпозиції складних систем будь-якого типу, у тому числі і програмних. Відповідно до цього підходу система складається з ієрархії рівнів. Кожен рівень обслуговує вище розміщений, виконуючи для нього деякий набір функцій, які утворюють міжрівневий інтерфейс (рис. 4). На основі функцій рівня розміщеного нижче наступний (вгору за ієрархією) рівень будує свої функції — складніші, які, у свою чергу, виявляються примітивами для створення ще складніших функцій рівня розміщеного вище. Строгі правила стосуються тільки взаємодії між рівнями системи, а між модулями всередині рівневі зв’язки можуть бути довільними. Окремий модуль може виконати свою роботу або самостійно, або звернутися до іншого модуля свого рівня, або звернутися по допомогу до нижчого рівня через міжрівневий інтерфейс.

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


Рис. 4. Концепція багаторівневої взаємодії

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

Ядро може складатися з наступних рівнів.


Засобів апаратної підтримки ОС. До цих пір про операційну систему говорилося як про комплекс програм, але, взагалі кажучи, частина функцій ОС може виконуватися і апаратними засобами. Тому іноді можна зустріти визначення операційної системи як сукупності програмних і апаратних засобів. До операційної системи відносять, звичайно, не всі апаратні пристрої комп’ютера, а тільки засоби апаратної підтримки ОС, тобто ті, які прямо беруть участь в організації обчислювальних процесів: засоби підтримки привілейованого режиму, систему переривань, засоби перемикання контексту процесів, засоби захисту областей пам’яті і т.п.


Машинно-залежні компоненти ОС. Цей рівень утворюють програмні модулі, в яких відбивається специфіка апаратної платформи комп’ютера. У ідеалі цей рівень повністю екранує вище розміщені рівні ядра від особливостей апаратури. Це дозволяє розробляти вище розміщені рівні на основі машинно-незалежних модулів, що існують в єдиному екземплярі для всіх типів апаратних платформ, підтримуваних даною ОС. Прикладом екрануючого рівня може служити рівень HAL операційної системи Windows NT.

Базові механізми ядра. Цей рівень виконує найбільш примітивні операції ядра, такі як програмне перемикання контексту процесів, диспетчеризацію переривань, переміщення сторінок з пам’яті на диск і назад і т.п. Модулі даного рівня не ухвалюють рішень про розподіл ресурсів — вони тільки відпрацьовують ухвалені «вгорі» рішення, що і дає привід називати їх виконавчими механізмами для модулів верхніх рівнів. Наприклад, рішення про те, що в даний момент потрібно перервати виконання поточного процесу А і почати виконання процесу, ухвалюється менеджером процесів на вище розміщеному рівні, а рівню базових механізмів передається тільки директива про те, що потрібно виконати перемикання з контексту поточного процесу на контекст процесу В.

Менеджери ресурсів. Цей рівень складається з потужних функціональних модулів, що реалізовують стратегічні завдання по управлінню основними ресурсами обчислювальної системи. Зазвичай на даному рівневі працюють менеджери (диспетчери) процесів, введення-виведення, файлової системи і оперативної пам’яті. Розбиття на менеджери може бути і дещо іншим, наприклад менеджер файлової системи іноді об’єднують з менеджером введення-виведення, а функції управління доступом користувачів до системи в цілому і її окремим об’єктам доручають окремому менеджерові безпеки. Кожний з менеджерів веде облік вільних і використовуваних ресурсів певного типу і планує їх розподіл відповідно до запитів прикладних програм. Наприклад, менеджер віртуальної пам’яті управляє переміщенням сторінок з оперативної пам’яті на диск і назад. Менеджер повинен відстежувати інтенсивність звернень до сторінок, час перебування їх в пам’яті, стани процесів, що використовують дані, і багато інших параметрів, на підставі яких він час від часу ухвалює рішення про те, які сторінки необхідно вивантажити і які — завантажити. Для виконання ухвалених рішень менеджер звертається до нижчого рівня базових механізмів із запитами про завантаження (вивантаження) конкретних сторінок. Всередині менеджерів існують тісні взаємні зв’язки, що відображають той факт, що для виконання процесу потрібний доступ одночасно до декількох ресурсів — процесора, області пам’яті, можливо, до певного файлу або пристрою введення-виведення. Наприклад, при створенні процесу менеджер процесів звертається до менеджера пам’яті, який повинен виділити процесу певну область пам’яті для його кодів і даних.

Інтерфейс системних викликів. Цей рівень є найвищим рівнем ядра він взаємодіє безпосередньо з прикладними програмами і системними утилітами, утворюючи прикладний програмний інтерфейс операційної системи. Функції API, які обслуговують системні виклики, надають доступ до ресурсів системи в зручній і компактній формі, без вказівки на деталі їх фізичного розташування. Наприклад, в операційній системі UNIX за допомогою системного виклику fd = open(“/doc/a.txt”, 0_RDONLY) програма відкриває файл а.txt, що зберігається в каталозі /doc, а за допомогою системного виклику reacKfd. buffer, count) читає з цього файлу в область свого адресного простору, що має ім’я buffer, деяку кількість байт. Для здійснення таких комплексних дій системні виклики зазвичай звертаються за допомогою до функцій менеджерів ресурсів, причому для виконання одного системного виклику може знадобитися декілька таких звернень.

Наведене розбиття ядра ОС на рівні є достатньо умовне. У реальній системі кількість рівнів і розподіл функцій між ними може бути й іншим. У системах, призначених для апаратних платформ одного типу, наприклад ОС NetWare, рівень машинно-залежних модулів зазвичай не виділяється, зливаючись з рівнем базових механізмів і, частково, з рівнем менеджерів ресурсів. Базові механізми не завжди оформляються в окремий рівень — в цьому випадку менеджери ресурсів не тільки планують використання ресурсів, але і самостійно реалізують свої плани.

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

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

Вибір кількості рівнів ядра є відповідальною і складною справою: збільшення числа рівнів веде до деякого уповільнення роботи ядра за рахунок додаткових накладних витрат на міжрівневу взаємодію, а зменшення їх числа погіршує розширюваність і логічність системи. Зазвичай операційні системи, які пройшли довгий шлях еволюційного розвитку, наприклад багато версій UNIX, мають неврегульоване ядро з невеликим числом чітко виділених рівнів, а у порівняно «молодих» операційних систем, таких як Windows NT, ядро розділене на більше число рівнів і їх взаємодію формалізовано набагато краще.

Апаратна незалежність і здатність до перенесення ОС

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

Типові засоби апаратної підтримки ОС

Чіткої межі між програмною і апаратною реалізацією функцій ОС не існує — рішення про те, які функції ОС виконуватимуться програмно, а які апаратно, приймається розробниками апаратного і програмного забезпечення комп’ютера. Проте практично всі сучасні апаратні платформи мають деякий типовий набір засобів апаратної підтримки ОС, в який входять наступні компоненти:

  • засоби підтримки привілейованого режиму;
  • засоби трансляції адрес;
  • засоби перемикання процесів;
  • система переривань;
  • системний таймер;
  • засоби захисту областей пам’яті.

Засоби підтримки привілейованого режиму зазвичай засновані на системному регістрі процесора, («словом стану») машини або процесора. Цей регістр містить деякі ознаки, що визначає режим роботи процесора, у тому числі і ознаку поточного режиму привілеїв. Зміна режиму привілеїв виконується за рахунок зміни слова стану машини в результаті переривання або виконання привілейованої команди. Число градацій привілейованої може бути різним у різних типах процесорів, найчастіше використовуються два рівні (ядро-користувач) або чотири (наприклад, ядро-супервізор-виконання-користувач у платформі VAX або 0-1-2-3 у процесорів Intel x86/Pentium). У обов’язки засобів підтримки привілейованого режиму входить виконання перевірки допустимості виконання активної програми інструкцій процесора при поточному рівні привілейованої.

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

Засоби перемикання процесів призначені для швидкого збереження контексту процесу, що припиняється, і відновлення контексту процесу, який стає активним. Вміст контексту зазвичай включає вміст всіх регістрів загального призначення процесора, регістра прапорів операцій (тобто прапорів нуля, перенесення, переповнювання і т. п.), а також тих системних регістрів і покажчиків, які пов’язані з окремим процесом, а не операційною системою, наприклад покажчика на таблицю трансляції адрес процесу. Для зберігання контекстів припинених процесів зазвичай використовуються області оперативної пам’яті, які підтримуються покажчиками процесора.

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

Система переривань дозволяє комп’ютеру реагувати на зовнішні події, синхронізувати виконання процесів і роботу пристроїв введення-виведення, швидко переходити з однієї програми на іншу. Механізм переривань необхідний для того, щоб оповістити процесор про виникнення в обчислювальній системі деякої непередбачуваної події або події, яка не синхронізована з циклом роботи процесора. Прикладами таких подій може бути завершення операції введення-виведення зовнішнім пристроєм (наприклад, запис блоку даних контроллером диска), некоректне завершення арифметичної операції (наприклад, переповнення регістру), закінчення інтервалу астрономічного часу. При виникненні умов переривання його джерело (контроллер зовнішнього пристрою, таймер, арифметичний блок процесора і т. п.) створює певний електричний сигнал. Цей сигнал перериває виконання процесором послідовності команд, що задається виконуваним кодом, і викликає автоматичний перехід на наперед певну процедуру, — процедурою обробки переривань. У більшості моделях процесорів відпрацьований апаратурою перехід на процедуру обробки переривань супроводжується заміною слова стану машини (або навіть всього контексту процесу), що дозволяє одночасно з переходом за потрібною адресою виконати перехід в привілейований режим. Після завершення обробки переривання зазвичай відбувається повернення до виконання перерваного коду.

Переривання грають найважливішу роль в роботі будь-якої операційної системи, будучи її рушійною силою. Дійсно, велика частина дій ОС ініціюється перериваннями різного типу. Навіть системні виклики від прикладних програм виконуються на багатьох апаратних платформах за допомогою спеціальної інструкції переривання, що викликає перехід до виконання відповідних процедур ядра (наприклад, інструкція int в процесорах Intel або SVC в мейнфреймах IBM).

Системний таймер, що часто реалізовується у вигляді швидкодіючого регістра-лічильника, необхідний операційній системі для витримки інтервалів часу. Для цього в регістр таймера програмно завантажується значення необхідного інтервалу в умовних одиницях, з якого потім автоматично з певною частотою починає відніматися по одиниці. Частота «тіків» таймера, як правило, тісно пов’язана з частотою тактового генератора процесора. (Не слід плутати таймер ні з тактовим генератором, який виробляє сигнали, що синхронізують всі операції в комп’ютері, ні з системним годинником — працюючій на батареях електронній схемі, — які ведуть незалежний відлік часу і календарної дати.) Досягши нульового значення лічильника таймер ініціює переривання, яке обробляється процедурою операційної системи. Переривання від системного таймера використовуються ОС в першу чергу для стеження за тим, як окремі процеси витрачають час процесора. Наприклад, в системі розділення часу при обробці чергового переривання від таймера планувальник процесів може примусово передати управління
іншому процесу, якщо даний процес вичерпав виділений йому квант часу.

Засоби захисту областей пам’яті забезпечують на апаратному рівні перевірку можливості програмного коду здійснювати з даними певної області пам’яті такі операції, як читання, запис або виконання (при передачах управління). Якщо апаратура комп’ютера підтримує механізм трансляції адрес, то засоби захисту областей пам’яті вбудовуються в цей механізм. Функції апаратури по захисту пам’яті зазвичай полягають в порівнянні рівнів привілеїв поточного коду процесора і сегменту пам’яті, до якого проводиться звернення.

Машинно-залежні компоненти ОС

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

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

Об’єм машинно-залежних компонентів ОС залежить від того, наскільки великі відмінності в апаратних платформах, для яких розробляється ОС. Наприклад, ОС, побудована на 32-бітових адресах, для перенесення на машину з 16-бітовими адресами повинна бути практично переписана наново. Одна з найбільш очевидних відмінностей — неспівпадання системи команд процесорів. Операційна система програмується на мові високого рівня, а потім відповідним компілятором виробляється код для
конкретного типу процесора. Проте у багатьох випадках відмінності в організації апаратури комп’ютера лежать набагато глибше і подолати їх таким чином не вдається. Наприклад, однопроцесорний і двороцесорний комп’ютери вимагають застосування в ОС абсолютно різних алгоритмів розподілу процесорного часу. Аналогічна відсутність апаратної підтримки віртуальної пам’яті приводить до принципової відмінності в реалізації підсистеми управління пам’яттю. У таких випадках не обійтися без внесення до коду операційної системи специфіки апаратної платформи, для якої ця ОС

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

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

Для комп’ютерів на основі процесорів Intel x86/Pentium розробка екрануючого машинно-залежного рівня ОС дещо спрощується за рахунок вбудованої в постійну пам’ять комп’ютера базової системи введення-виведення — BIOS. BIOS містить драйвери для всіх пристроїв, що входять в базову конфігурацію комп’ютера: жорстких і гнучких дисків, клавіатури, дисплея і т.д. Ці драйвери виконують вельми примітивні операції з керованими пристроями, наприклад читання групи секторів даних з певної доріжки диска, але за рахунок цих операцій екрануються відмінності апаратних платформ персональних комп’ютерів і серверів на процесорах Intel різних виробників. Розробники операційної системи можуть користуватися рівнем драйверів BIOS як частиною машинно-залежного рівня ОС, а можуть і замінити все або частину драйверів BIOS компонентами ОС.

Здатність операційної системи до перенесення

Якщо код операційної системи може бути порівняно легко перенесений з процесора одного типу на процесор іншого типу і з апаратної платформи одного типу на апаратну платформу іншого, то таку ОС називають здатною до перенесення(portable), або мобільною.

Хоча ОС часто описуються як здатними до перенесення мобільність — це не бінарний стан, а поняття ступеня. Питання не в тому, чи може бути система перенесена, а в тому, наскільки легко можна це зробити. Для того, щоб забезпечити властивість мобільності ОС, розробники повинні слідувати наступним правилам.

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

Об’єм машинно-залежних частин коду, які безпосередньо взаємодіють з апаратними засобами, повинен бути по можливості мінімізований. Так, наприклад, слід всіляко уникати прямого маніпулювання регістрами і іншими апаратними засобами процесора. Для зменшення апаратної залежності розробники ОС повинні також виключити можливість використання за замовченням стандартних конфігурацій апаратури або їх характеристик. Апаратно-залежні параметри можна «заховати» в дані абстрактного типу, що задаються програмно. Для здійснення всіх необхідних дій по управлінню апаратурою, представленою цими параметрами, повинен бути написаний набір апаратно-залежних функцій. Кожного разу, коли якому-небудь модулю ОС потрібно виконати деяку дію, пов’язану з апаратурою, він маніпулює абстрактними даними, використовуючи відповідну функцію з наявного набору. Коли ОС переноситься, то змінюються тільки ці дані і функції, які ними маніпулюють. Наприклад, в ОС Windows NT диспетчер переривань перетворить апаратні рівні переривань конкретного типу процесора в стандартний .набор рівнів переривань IRQL, з якими працює решта модулів операційної системи. Тому при перенесенні Windows NT на нову платформу потрібно переписати, зокрема, ті коди диспетчера переривань, які займаються відображенням рівнів переривання на абстрактні рівні IRQL, а ті модулі ОС, які користуються цими абстрактними рівнями, змін не потребують.

Апаратно-залежний код повинен бути надійно ізольований в декількох модулях, а не бути розподілений по всій системі. Ізоляції підлягають всі частини ОС, які відображають специфіку як процесора, так і апаратної платформи в цілому. Низькорівневі компоненти ОС, що мають доступ до процесорно-залежних структур даних і регістрів, повинні бути оформлені у вигляді компактних модулів, які можуть бути замінені аналогічними модулями для інших процесорів. Для зняття залежності платформи, що виникає через відмінності між комп’ютерами різних виробників, побудованими на одному і тому ж процесорі (наприклад, MIPS R4000), повинен бути введений добре локалізований програмний рівень машинно-залежних функцій.

В ідеалі рівень машинно-залежних компонентів ядра повністю екранує решту частин ОС від конкретних деталей апаратної платформи (кешу, контроллери переривань введення-виведення і т. п.), принаймні для того набору платформ, який підтримує дана ОС. В результаті відбувається підміна реальної апаратури якоюсь уніфікованою віртуальною машиною, однаковою для всіх варіантів апаратної платформи. Всі рівні операційної системи, які розміщуються вище за рівень машинно-залежних компонентів, можуть бути написані для управління саме цією віртуальною апаратурою. Таким чином, у розробників з’являється можливість створювати один варіант машинно-незалежної частини ОС (включаючи компоненти ядра, утиліти, системні оброблювальні програми) для всього набору підтримуваних платформ (рис. 5).


Рис. 5. Перенесення операційної системи на різні апаратні платформи

Мікроядерна архітектура

Мікроядерна архітектура є альтернативою класичному способу побудови операційної системи. Під класичною архітектурою в даному випадку розуміється розглянута вище структурна організація ОС, відповідно до неї всі
основні функції операційної системи, які складають багаторівневе ядро, виконуються в привілейованому режимі. При цьому деякі допоміжні функції ОС оформляються у вигляді прикладних програм і виконуються в режимі призначеному для користувача разом із звичайними програмами (стаючи системними утилітами або оброблювальними програмами). Кожна прикладна програма режиму користувача працює у власному адресному просторі і захищена тим самим від якого-небудь втручання інших програм. Код ядра, який виконується в привілейованому режимі, має доступ до областей пам’яті всіх програм, але сам повністю захищений від них. На виконання системних функцій прикладні програми звертаються із запитами до ядра.

Суть мікроядерної архітектури полягає в наступному. У привілейованому режимі залишається працювати тільки дуже невелика частина ОС, — мікроядро. Мікроядро захищене від решти частин ОС і програм. До його складу зазвичай входять машинно-залежні модулі, а також модулі, що виконують базові (але не всі!) функції ядра по управлінню процесами, обробці переривань, управлінню віртуальною пам’яттю, пересилці повідомлень і управлінню пристроями введення-виведення, пов’язані із завантаженням або читанням регістрів пристроїв. Набір функцій мікроядра зазвичай відповідає функціям рівню базових механізмів звичайного ядра. Такі функції операційної системи виконати важко, або ж неможливо виконати в режимі користувача.

Решта всіх більш високорівневих функцій ядра оформляється у вигляді прикладних програм, які працюють в режимі користувача. Однозначного рішення про те, які з системних функцій потрібно залишити в привілейованому режимі, а які перенести в режим користувача, не існує. У загальному випадку багато менеджерів ресурсів, що є невід’ємними частинами звичайного ядра, — файлова система, підсистеми управління віртуальною пам’яттю і процесами, менеджер безпеки і т. п., — стають «периферійними» модулями, та виконуються в режимі користувача.

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

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

Схемний механізм звернення до функцій ОС, оформлених у вигляді серверів, виглядає таким чином (рис. 6). Клієнт, яким може бути або прикладна програма, або інший компонент ОС, запрошує виконання деякої функції у відповідного сервера, посилаючи йому повідомлення. Безпосередня передача повідомлень між прикладними програмами неможлива, оскільки їх адресні простори ізольовані один від одного. Мікроядро, яке виконується в привілейованому режимі, має доступ до адресних просторів кожної з цих програм і тому може працювати як посередник. Мікроядро спочатку передає повідомлення, що містить ім’я і параметри процедури, що викликається, потрібному серверу, потім сервер виконує запитану операцію, після чого ядро повертає результати клієнтові за допомогою іншого повідомлення. Таким чином, робота мікроядерної операційної системи відповідає відомій моделі клієнт-сервер, в якій роль транспортних засобів виконує мікроядро.


Рис. 6. Реалізація системного виклику в мікроядерній архітектурі

Переваги і недоліки мікроядерної архітектури

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

Висока здатність до перенесення обумовлена тим, що весь машинно-залежний код ізольований в мікроядрі, тому для перенесення системи на новий процесор треба вносити менше змін і всі вони логічно пов’язані.

Розширюваність властива мікроядерній ОС в дуже великій мірі. У традиційних системах навіть за наявності багатрівневої структури нелегко видалити один рівень і поміняти його на інший внаслідок множинності і розмитості інтерфейсів між рівнями. Зміна і додавання нових функцій вимагають від програміста високих знань операційних систем і великих затрат часу. В той же час обмежений набір певних інтерфейсів мікроядра відкриває шлях до впорядкованого зростання і еволюції ОС. Додавання нової підсистеми вимагає розробки нової програми, що ніяк не зачіпає цілісність мікроядра. Мікроядерна структура дозволяє не тільки додавати, але і скорочувати число компонентів операційної системи, що також буває дуже корисно. Наприклад, не всім користувачам потрібні засоби безпеки або підтримки розподілених обчислень, а видалення їх з традиційного ядра найчастіше неможливо. Зазвичай традиційні операційні системи дозволяють динамічно додавати в ядро або видаляти з ядра тільки драйвери зовнішніх пристроїв — зважаючи на часті зміни в конфігурації підключених до комп’ютера зовнішніх пристроїв підсистема введення-виведення ядра допускає завантаження і вивантаження драйверів «на ходу», але для цього вона розробляється особливим чином (наприклад, середовище STREAMS в UNIX або менеджерові введення-виведення в Windows NT). При мікроядерному підході конфігурування ОС не викликає жодних проблем і не вимагає особливих заходів — досить змінити файл з настройками початкової конфігурації системи або ж в ході роботи зупинити не потрібні сервери звичайними для зупинки програм засобами.

Використання мікроядерної моделі підвищує надійність ОС. Кожен сервер виконується у вигляді окремого процесу в своїй власній області пам’яті і таким чином захищений від інших серверів операційної системи, що не спостерігається в традиційній ОС, де всі модулі ядра можуть впливати один на одного. І якщо окремий сервер терпить крах, то він може бути перезапущений без зупинки або пошкодження решти серверів ОС. Більш того, оскільки сервери виконуються в режимі користувача, вони не мають безпосереднього доступу до апаратури і не можуть модифікувати пам’ять, в якій зберігається і працює мікроядро. Іншим потенційним джерелом підвищення надійності ОС є зменшений об’єм коду мікроядра в порівнянні з традиційним ядром — це знижує вірогідність появи помилок програмування.

Модель з мікроядром добре підходить для підтримки розподілених обчислень, оскільки використовує механізми, аналогічні мережевим: взаємодія клієнтів і серверів шляхом обміну повідомленнями. Сервери мікроядерної ОС можуть працювати як на одному, так і на різних комп’ютерах. В цьому випадку при отриманні повідомлення від програми мікроядро може обробити його самостійно і передати локальному серверу або ж переслати по мережі мікроядру, що працює на іншому комп’ютері. Перехід до розподіленої обробки вимагає мінімальних змін в роботі операційної системи — просто локальний транспорт замінюється на мережевий.

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


Рис. 7. Зміна режимів при виконанні системного виклику

Серйозність цього недоліку добре ілюструє історія розвитку Windows NT. У версіях 3.1 і 3.5 диспетчер вікон, графічна бібліотека і високорівневі драйвери графічних пристроїв входили до складу сервера режиму користувача, і виклик функцій цих модулів здійснювався відповідно до мікроядерної схеми. Проте дуже скоро розробники Windows NT зрозуміли, що такий механізм звернень до часто використовуваних функцій графічного інтерфейсу істотно сповільнює роботу прикладних програм і робить дану операційну систему вразливою в умовах гострої конкуренції. В результаті до версії Windows NT 4.0 були внесені істотні зміни — всі перераховані вище модулі були перенесені в ядро, що віддалило цю ОС від ідеальної мікроядерної архітектури, та зате різко підвищило її продуктивність.

Цей приклад ілюструє головну проблему, з якою стикаються розробники операційної системи, які вирішили застосувати мікроядерний підхід, — що включати в мікроядро, а що виносити в простір користувача. У ідеальному випадку мікроядро може складатися тільки із засобів передачі повідомлень, засобів взаємодії з апаратурою, зокрема засобів доступу до механізмів привілейованого захисту. Проте багато розробників не завжди жорстко дотримуються принципу мінімізації функцій ядра, часто жертвуючи цим заради підвищення продуктивності. В результаті реалізації ОС утворюють деякий спектр, на одному краю якого знаходяться системи з мінімально можливим мікроядром, а на іншому — системи, подібні Windows NT, в яких мікроядро виконує чималий об’єм функцій.

Сумісність і множинні прикладні середовища

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

Бінарна сумісність і сумісність вихідних текстів

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

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

Сумісність на рівні вихідних текстів важлива в основному для розробників програм, у розпорядженні яких ці тексти завжди є. Але для кінцевих користувачів практичне значення має тільки бінарна сумісність, оскільки тільки в цьому випадку вони можуть використовувати один і той же комерційний продукт, що поставляється у вигляді двійкового виконуваного коду, в різних операційних середовищах і на різних машинах. Для користувача, який купив свого часу пакет (наприклад, Lotus 1-2-3) для MS-DOS, важливо, щоб він міг запускати цей пакет, без яких-небудь змін і на своїй новій машині, що працює під управлінням, наприклад, Windows NT.

Чи володіє нова ОС бінарною сумісністю або сумісністю вихідних текстів з існуючими операційними системами, залежить від багатьох чинників. Найголовніший з них — архітектура процесора, на якому працює нова ОС. Якщо процесор використовує той же набір команд (можливо, з деякими додаваннями) і той же діапазон адрес, тоді двійкова сумісність може бути досягнута досить просто. Для цього достатньо дотримання наступних умов:

виклики функцій API, які містить програму, повинні підтримуватися дану ОС;

внутрішня структура виконуваного файлу програми повинна відповідати ОС.

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

Хай, наприклад, потрібно виконати DOS-програму для IBM PC-сумісного комп’ютера на комп’ютері Macintosh. Комп’ютер Macintosh побудований на основі процесора Motorola 680×0, а комп’ютер IBM PC — на основі процесора Intel 80×86. Процесор Motorola має архітектуру (систему команд, склад регістрів і т. п.), відмінну від архітектури процесора Intel, тому йому незрозумілий двійковий код DOS-програми, що містить інструкції цього процесора. Для того, щоб комп’ютер Macintosh зміг інтерпретувати машинні інструкції, які йому спочатку незрозумілі, на ньому повинні бути встановлене спеціальне програмне забезпечення — емулятор.

Емулятор повинен послідовно вибирати кожну двійкову інструкцію процесора Intel, програмним способом дешифрувати її, щоб визначити, які дії вона задає, а потім виконувати еквівалентну підпрограму, написану в інструкціях процесора Motorola. Оскільки до того ж у процесора Motorola немає в точності таких же регістрів, прапорів і внутрішнього арифметико-логічного устрою, як в Intel, він повинен також імітувати (емулювати) всі ці елементи з використанням своїх регістрів або пам’яті. Стан емульованих регістрів і прапорів після виконання кожної команди повинен бути абсолютно таким же, як і в реальному процесорі Intel.

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

Трансляція бібліотек

Виходом в таких випадках є використання так званих прикладних програмних середовищ. Однією з складових, що формують прикладне програмне середовище, є набір функцій інтерфейсу прикладного програмування API, які операційна система надає своїм програмам. Для скорочення часу на виконання “чужих” програм прикладні середовища імітують звернення до бібліотечних функцій.

Ефективність цього підходу пов’язана з тим, що більшість сьогоднішніх програм працюють під управлінням GUI (графічних інтерфейсів користувача) типу Windows, Mac або UNIX Motif, при цьому прикладні програми витрачають багато часу, проводячи деякі добре передбачені дії. Вони безперервно виконують виклики бібліотек GUI для маніпулювання вікнами і для інших пов’язаних з GUI дій. Сьогодні в типових програмах 60-80 % часу витрачається на виконання функцій GUI та інших бібліотечних викликів ОС. Саме ця властивість програм дозволяє прикладним середовищам компенсувати великі витрати часу, затрачені на емуляцію програми. Ретельно спроектоване програмне прикладне середовище має в своєму складі бібліотеки, що імітують внутрішні бібліотеки GUI, але написані на «рідному» коді. Таким чином досягається істотне прискорення виконання програм з API іншої операційної системи. Іноді такий підхід називають трансляцією для того, щоб відрізняти його від повільнішого процесу емуляції коду по одній команді за раз.

Наприклад, для Windows-програми, що працює на Macintosh, при інтерпретації команд процесора Intel 80×86 продуктивність може бути дуже низькою. Але коли проводиться виклик функції GUI відкриття вікна, модуль ОС, що реалізовує прикладне середовище Windows, може перехопити цей виклик і перенаправити його на перекомпільовану для процесора Motorola 680×0 підпрограму відкриття вікна. В результаті на таких ділянках коду швидкість роботи програми може досягти (а можливо, і перевершити) швидкість роботи на своєму «рідному» процесорі.

Щоб програма, написана для однієї ОС, могла бути виконана в рамках іншої ОС, недостатньо лише забезпечувати сумісність API. Концепції, покладені в основу різних ОС, можуть входити в суперечність один з одним. Наприклад, в одній операційній системі прикладній програмі може бути дозволено безпосередньо управляти пристроями введення-виведення, в іншій — ці дії є прерогативою ОС. Кожна операційна система має свої власні механізми захисту ресурсів, свої алгоритми обробки помилок і виняткових ситуацій, особливу структуру процесу і схему управління пам’яттю, свою семантику доступу до файлів і графічний призначений для користувача інтерфейс. Для забезпечення сумісності необхідно організувати безконфліктне співіснування в рамках однієї ОС декількох способів управління ресурсами комп’ютера.

Способи реалізації прикладних програмних середовищ

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

У багатьох версіях ОС UNIX транслятор прикладних середовищ реалізується у вигляді звичайної прикладної програми. У операційних системах, побудованих з використанням мікроядерної архітектури, таких як, наприклад, Windows NT або Workplace OS, прикладні середовища виконуються у вигляді серверів в режимі користувача. А в OS/2 з її більш простою архітектурою засобів організації прикладних середовищ вони глибоко вбудовані в операційну систему.

Один з найбільш очевидних варіантів реалізації множинних прикладних середовищ грунтується на стандартній багаторівневій структурі ОС. На рис. 8 операційна система OS 1 підтримує окрім своїх «рідних» прикладних програм програми операційних систем OS2 і OS3. Для цього в її складі є спеціальні програми — прикладні програмні середовища, — які транслюють інтерфейси «чужих» операційних систем API OS2 і API OS3 в інтерфейс своєї «рідної» операційної системи — API OS1. Так, наприклад, у випадку, якщо б як OS2 виступала операційна система UNIX, а як OS1 — OS/2, для виконання системного виклику створення процесу forkO в UNIX-застосуванні програмне середовище повинне звернутися до ядра операційної системи OS/2 з системним викликом DosExecPgmO.


Рис. 8. Прикладні програмні середовища, які транслюють системні виклики

На жаль, поведінка майже всіх функцій, складових API однієї ОС, як правило, істотно відрізняється від поведінки відповідних функцій іншої ОС. Наприклад, щоб функція створення процесу в OS/2 DosExecPgmO повністю відповідала функції створення процесу forkO в UNIX-подібних системах, її потрібно було б змінити так, щоб вона підтримувала можливість копіювання адресного простору батьківського процесу в простір процесу-нащадка. (При нормальній же поведінці цієї функції пам’ять процесу-нащадка ініціалізувалася на основі даних нового виконуваного файлу.)

У іншому варіанті реалізації множинних прикладних середовищ операційна система має декілька рівноправних прикладних програмних інтерфейсів. У наведеному на рис. 9 прикладі операційна система підтримує програми, написані для OS1, OS2 і OS3. Для цього безпосередньо в просторі ядра системи розміщені прикладні програмні інтерфейси всіх цих ОС: API OS1, API OS2 і API OS3.

У цьому варіанті функції рівня API звертаються до функцій нижчого рівня ОС, які повинні підтримувати всі три в загальному випадку несумісні прикладні середовища. У різних ОС по-різному здійснюється управління системним часом, використовується різний формат часу дня, на підставі власних алгоритмів розділяється процесорний час і т.д. Функції кожного API реалізуються ядром з урахуванням специфіки відповідної ОС, навіть якщо вони мають аналогічне призначення. Наприклад, як вже було сказано, функція створення процесу працює по-різному для програми UNIX і програм OS/2. Аналогічно при завершенні процесу ядра також необхідно визначати, до якої ОС відноситься даний процес. Якщо цей процес був створений по запиту UNIX-програми, то в ході його завершення ядро повинне послати батьківському процесу сигнал, як це робиться в ОС UNIX. А після закінчення процесу OS/2, створеного з параметром EXEC_SYNC, ядро повинне відзначити, що ідентифікатор процесу не може бути повторно використаний іншим процесом OS/2. Для того, щоб ядро могло вибрати потрібний варіант реалізації системного виклику, кожен процес повинен передавати в ядро набір ідентифікуючих характеристик.


Рис. 9. Реалізація сумісності на основі декількох рівноправних API

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

Відповідно до мікроядерної архітектури всі функції ОС реалізуються мікроядром і серверами в режимі користувача. Важливо, що кожне прикладне середовище оформляється у вигляді окремого сервера в режимі користувача і не включає базових механізмів (рис. 10). Програми, які використовують API, звертаються з системними викликами до відповідного прикладного середовища через мікроядро. Прикладне середовище обробляє запит, виконує його (можливо, звертаючись для цього по допомогу до базових функцій мікроядра) і посилає програмі результат. В ході виконання запиту прикладному середовищу доводиться, у свою чергу, звертатися до базових механізмів ОС, мікроядром, що реалізовується, і іншими серверами ОС.

Такому підходу до конструювання можинних прикладних середовищ властиві всі переваги і недоліки мікроядерної архітектури, зокрема:

  • дуже просто можна додавати і виключати прикладні середовища, що є наслідком хорошої розширюваності мікроядерних ОС;
  • надійність і стабільність виражаються в тому, що при відмові одного з прикладних середовищ всі інші зберігають працездатність;
  • низька продуктивність мікроядерних ОС позначається на швидкості роботи прикладних середовищ, а значить, і на швидкості виконання прикладних програм.


Рис. 10. Мікроядерний підхід до реалізації множинних прикладних середовищ

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

 

Висновок

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

По відношенню до інших програм ядро ОС повинно мати певні переваги. Інші програми не повинні втручатись в роботу ядра і водночас ядро має втрутитись в роботу інших програм наприклад для вирішення конфлікту в боротьбі за ресурси. Для цього процесор підтримує два режими роботи – привілейований і режим користувача.

При розгляді операційної системи її умовно поділяють на рівні. Таким чином нижній рівень утворює апаратура, проміжний — ядро, а утиліти, оброблювальні і прикладні програми, складають верхній рівень системи. Ядро є складним багатофункціональним комплексом, тому багаторівневий підхід зазвичай розповсюджується і на структуру ядра. Ядро може складатися з наступних рівнів: засобів апаратної підтримки ОС,
машинно-залежних компонент ОС,
базових механізмів ядра,
менеджера ресурсів, інтерфейсу системних викликів. Багаторівневий підхід є універсальним і ефективним способом у створенні складних систем будь-якого типу, у тому числі і програмних.

Сучасні апаратні архітектури комп’ютерів реалізують базові засоби підтримки ОС. До них належать: засоби підтримки привілейованого режиму,
засоби трансляції адрес, засоби перемикання процесів, система переривань, системний таймер, засоби захисту областей пам’яті.

Здатність операційних систем працювати на різних апаратних платформах називається здатністю ОС до перенесення. Такі ОС повинні відповідати наступним вимогам:

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

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

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

Програмна сумісність означає можливість виконувати в середовищі однієї системи програми, розроблені для іншої ОС. Розрізняють сумісність на рівні вихідних текстів та бінарну сумісність. Для сумісності на рівні вихідних текстів необхідно, щоб для всіх ОС існувала реалізація компілятора мови (С, С++) і АРІ, що його використовує програма. Бінарну сумісність забезпечує емуляція середовища виконання прикладної програми в середовищі іншої ОС.

 

Список використаної літератури

  1. Таненбаум Э. Современные операционные системы. 2-е изд. – СПб.: Питер, 2002. – 1040 с.: ил.
  2. В.Г. Олифер, Н.А. Олифер Сетевые операционные системы – СПб.: Питер, 2002. – 544 с.: ил.
  3. Шеховцов В. A. Операційні системи – К.:Видавнича група ВНV, 2005. – 576 с.:іл.
ЗАВАНТАЖИТИ

Для скачування файлів необхідно або Зареєструватись

АРХІТЕКТУРА ОПЕРАЦІЙНИХ СИСТЕМ (97.7 KiB, Завантажень: 11)

завантаження...
WordPress: 23.33MB | MySQL:26 | 1,214sec