• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Особливості архітектури: Windows ХР

Операційна система та її оточення

Реалізація архітектури операційних систем

Тема: Архітектура операційних систем

Лекція 2

Кандидат юридичних наук

В И С Н О В О К

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

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

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

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

Іваньков І.В.

План:

1. Базові поняття архітектури операційних систем;

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

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

У цьому розділі ми ознайомимося з основними поняттями архітектури опера­ційних систем, підходами до її реалізації, особливостями взаємодії ОС із зовні­шнім середовищем. Реалізацію архітектури буде розглянуто на прикладах UNIX, Linux і Windows ХР.

1. Базові поняття архітектури операційних систем

1.1. Механізми і політика

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

Коли за реалізацію механізму і політики відповідають різні компоненти (меха­нізм відокремлений від політики), спрощується розробка системи і підвищується її гнучкість. Компонентам, що реалізують механізм, не повинна бути доступна ін­формація про причини та цілі його застосування; усе, що потрібно від них, — це виконувати призначену їм роботу. Для таких компонентів використовують тер­мін «вільні від політики» (policy-free). Компоненти, відповідальні за політику, мають оперувати вільними від неї компонентами як будівельними блоками, для них недоступна інформація про деталі реалізації механізму.

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

1.2. Ядро системи. Привілейований режим і режим Користувача

Базові компоненти ОС, які відповідають за найважливіші її функції, зазвичай пе­ребувають у пам'яті постійно і виконуються у привілейованому режимі, назива­ють ядром операційної системи (operating system kernel).

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

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

Для забезпечення ефективного керування ресурсами комп'ютера ОС повинна мати певні привілеї щодо прикладних програм. Треба, щоб прикладні програми не втручалися в роботу ОС, і водночас ОС повинна мати можливість втрутитися в роботу будь-якої програми, наприклад для перемикання процесора або роз­в'язання конфлікту в боротьбі за ресурси. Для реалізації таких привілеїв потрібна апаратна підтримка: процесор має підтримувати принаймні два режими роботи - привілейований (захищений режим, режим ядра, kernel mode) і режим користува­ча (user mode). У режимі користувача недопустимі команди, які є критичними для роботи системи (перемикання задач, звертання до пам'яті за заданими межа­ми, доступ до пристроїв введення-виведення тощо).

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

Після завантаження ядро перемикає процесор у привілейований режим і отри­мує цілковитий контроль над комп'ютером. Кожне застосування запускається і виконується в режимі користувача, де воно не має доступу до ресурсів ядра й ін­ших програм. Коли потрібно виконати дію, реалізовану в ядрі, застосування ро­бить системний виклик (system call). Ядро перехоплює його, перемикає процесор у привілейований режим, виконує дію, перемикає процесор назад у режим кори­стувача і повертає результат застосування.

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

1.3. Системне програмне забезпечення

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

· системні програми (утиліти), наприклад: командний інтерпретатор, програми резервного копіювання та відновлення даних, засоби діагностики та адміні­стрування;

· системні бібліотеки, у яких реалізовані функції, що використовуються у за­стосуваннях користувача.

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

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

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

2.1. Монолітні системи

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

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

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

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

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

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

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

♦ Базові засоби ядра, які відповідають за найфундаментальніші, найпростіші дії ядра, такі як запис блоку даних на диск. За допомогою цих засобів виконують­ся вказівки верхніх рівнів, пов'язані з керуванням ресурсами.

♦ Засоби керування ресурсами (або менеджери ресурсів), що реалізують основні функції ОС (керування процесами, пам'яттю, вводом-виводом тощо). На цьому рівні приймаються найважливіші рішення з керування ресурсами, які виконуються з використанням базових засобів ядра.

♦ Інтерфейс системних викликів, який служить для реалізації зв'язку із систем­ним і прикладним програмним забезпеченням.

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

2.3. Системи з мікроядром

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

Мікроядро здійснює зв'язок між компонентами системи і виконує базовий розподіл ресурсів. Щоб виконати системний виклик, процес (клієнтський процес, клієнт) звертається до мікроядра. Мікроядро посилає серверу запит, сервер вико­нує роботу і пересилає відповідь назад, а мікроядро переправляє його клієнтові (рис. 2.1). Клієнтами можуть бути не лише процеси користувача, а й інші модулі ОС.

Перевагами мікроядрового підходу є:

· невеликі розміри мікроядра, що спрощує його розробку й налагодження;

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

· більша гнучкість і розширюваність системи (непотрібні компоненти не займа­ють місця в пам'яті, розширення функціональності системи зводиться до до­давання в неї нового сервера);

· можливість адаптації до умов мережі (спосіб обміну даними між клієнтом і сервером не залежить від того, зв'язані вони мережею чи перебувають на од­ному комп'ютері).

Виконання системного виклику в архітектурі з мікроядром

Головним недоліком мікроядрового підходу є зниження продуктивності. За­мість двох перемикань режиму процесора у разі системного виклику відбуваєть­ся чотири (два — під час обміну між клієнтом і мікроядром, два — між сервером та мікроядром).

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

2.4. Концепція віртуальних машин

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

Уперше концепція віртуальних машин була реалізована в 70-ті роки в опера­ційній системі VM фірми IBM. У СРСР варіант цієї системи (VM/370) був ши­роко розповсюджений у 80-ті роки і мав назву Система віртуальних машин ЄС ЕОМ (СВМ ЄС). Розглянемо архітектуру цієї ОС [8,44], що показана на рис. 2.2.

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

Коли програма, написана для ПДО, виконувала системний виклик, його пере­хоплювала копія ПДО, запущена на відповідній віртуальній машині. Потім ПДО виконувала відповідні апаратні інструкції, наприклад інструкції введення-виве­дення для читання диска. Ці інструкції перехоплював МВМ і перетворював їх на апаратні інструкції фізичної машини.

Архітектура VM/370 [44]

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

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

3. Операційна система та її оточення

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

3. 1. Взаємодія ОС і апаратного забезпечення

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

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

Засоби апаратної підтримки операційних систем

Сучасні апаратні архітектури комп'ютерів реалізують базові засоби підтримки операційних систем. До них належать: система переривань, привілейований режим процесора, засоби перемикання задач, підтримка керування пам'яттю (ме­ханізми трансляції адрес, захист пам'яті), системний таймер, захист пристроїв введення-виведення, базова система введення-виведення (BIOS). Розглянемо ці засоби докладніше.

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

Апаратне переривання — це спеціальний сигнал (запит переривання, IRQ), що передається процесору від апаратного пристрою.

До апаратних переривань належать:

· переривання введення-виведення, що надходять від контролера периферій­ного пристрою; наприклад, таке переривання генерує контролер клавіатури при натисканні на клавішу;

· переривання, пов'язані з апаратними або програмними помилками (такі пере­ривання виникають, наприклад, у разі збою контролера диска, доступу до за­бороненої області пам'яті або ділення на нуль).

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

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

За встановлення оброблювачів переривань зазвичай відповідає ОС. Можна сказати, що сучасні ОС керовані перериваннями (interrupt-driven), бо, якщо ОС не зайнята виконанням якої-небудь задачі, вона очікує на переривання, яке й за­лучає її до роботи.

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

Засоби перемикання задач дають змогу зберігати вміст регістрів процесора (контекст задачі) у разі припинення задачі та відновлювати дані перед її подальшим виконанням.

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

Захист пам'яті забезпечує перевірку прав доступу до пам'яті під час кожної спроби його отримати. Засоби захисту пам'яті інтегровані з механізмами транс­ляції адрес: у таблицях трансляції утримується інформація про права, необхідні для їхнього використання, і про ліміт (розміри ділянки пам'яті, до якої можна отримати доступ з їхньою допомогою). Неможливо одержати доступ до пам'яті поверх ліміту або за відсутності прав на використання таблиці трансляції.

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

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

Базова система вводу-виводу (BIOS) — службовий програмний код, що зберігається в постійному запам'ятовувальному пристрої і призначений для ізо­ляції ОС від конкретного апаратного забезпечення. Зазначимо, що засоби BIOS не завжди дають змогу використати всі можливості архітектури: наприклад, про­цедури BIOS для архітектури ІА-32 не працюють у захищеному режимі. Тому су­часні ОС використовують їх тільки для початкового завантаження системи.

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

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

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

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

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

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

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

3. 2. Взаємодія ОС і виконуваного програмного коду

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

Системні виклики та інтерфейс програмування застосувань

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

Розглянемо послідовність виконання системного виклику.

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

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

3. Після отримання керування ядро зчитує параметри виклику і визначає, що потрібно зробити.

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

5. Програма зчитує з пам'яті повернені значення і продовжує свою роботу.

Як бачимо, кожний системний виклик спричиняє перехід у привілейований режим і назад (у мікроядровій архітектурі, як було зазначено вище, таких перехо­дів може бути і більше).

Розглянемо способи передачі параметрів у системний виклик. До них належать:

· передача параметрів у регістрах процесора;

· занесення параметрів у певну ділянку пам'яті й передача покажчика на неї в регістрі процесора.

Системні виклики призначені для безпосереднього доступу до служб ядра ОС. На практиці вони не вичерпують (а іноді й не визначають) ті функції, які можна використати у прикладних програмах для доступу до служб ОС або засобів си­стемних бібліотек. Для позначення цього набору функцій використовують термін інтерфейс програмування застосувань (Application Programming Interface, API).

Взаємозв'язок між функціями АРІ і системними викликами неоднаковий у різних ОС.

По-перше, кожному системному виклику може бути поставлена у відповід­ність бібліотечна функція, єдиним завданням якої є виконання цього виклику. Таку функцію називають пакувальником системного виклику (system call wrapper). Для програміста в цьому разі набір функцій АРІ виглядає як сукупність таких па­кувальників і додаткових функцій, реалізованих бібліотеками повністю або част­ково в режимі користувача. Це рішення прийняте за основу в UNIX; у такому разі прийнято говорити про використання системних викликів у прикладних програ­мах (насправді у програмах викликають пакувальники системних викликів).

По-друге, можна надати для використання у прикладних програмах універ­сальний інтерфейс програмування застосувань (АРІ режиму користувача) і пов­ністю сховати за ним набір системних викликів. Для програміста кожна функція такого АРІ є бібліотечною функцією режиму користувача, пакувальника в цьому разі немає, відомості про системні виклики є деталями реалізації ОС. Це вла­стиве Windows-системам, де подібний універсальний набір функцій називають Win32 АРІ [31, 50].

Програмна сумісність

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

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

Для сумісності на рівні вихідних текстів необхідно, щоб для всіх ОС існувала реалізація компілятора мови і АРІ, що його використовує програма.

Сьогодні таку сумісність забезпечує стандартизація розробки програмного за­безпечення, а саме:

· наявність стандарту на мови програмування (насамперед на С і С++) і стан­дартних компіляторів;

· наявність стандарту на інтерфейс операційної системи (АРІ).

Робота зі стандартизації інтерфейсу операційних систем відбувається у рам­ках проекту POSIX (Portable Operating System Interface). Найбільш важливим стандартом є POSIX 1003.1 [3], який описує набір бібліотечних процедур (таких, як відкриття файлу, створення нового процесу тощо), котрі мають бути реалізовані в системі. Цей процес стандартизації триває дотепер, останньою редакцією стан­дарту є базова специфікація Open Group/IEEE [103]. Зазначені стандарти ві­дображають традиційний набір засобів, реалізованих в UNIX- сумісних системах.

Завдання забезпечення бінарної сумісності виникає тоді, коли потрібно за­пустити на виконання файл прикладної програми у середовищі іншої операцій­ної системи. Таке завдання значно складніше в реалізації, найпоширеніший під­хід до його розв'язання - емуляція середовища виконання. У цьому разі програма запускається під керуванням іншої програми — емулятора, який забезпечує ди­намічне перетворення інструкцій програми в інструкції потрібної архітектури. Прикладом такого емулятора є програма wine, яка дає можливість запускати про­грами, розроблені для Win32 АРІ, у середовищі Linux через емуляцію функцій Win32 АРІ системними викликами Linux.

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

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

UNIX є прикладом досить простої архітектури ОС. Більша частина функціональ­ності цієї системи міститься в ядрі, ядро спілкується із прикладними програмами за допомогою системних викликів. Базова структура класичного ядра UNIX зобра­жена на рис. 2.3 (див., наприклад, [33, 59]).

Архітектура UNIX

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

Підсистема керування процесами контролює створення та вилучення проце­сів, розподілення системних ресурсів між ними, міжпроцесову взаємодію, керу­вання пам'яттю.

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

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

Сучасні UNIX-системи дещо відрізняються за своєю архітектурою.

♦ У них виділено окремий менеджер пам'яті, відповідальний за підтримку вір­туальної пам'яті.

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

♦ У цих системах підтримується багатопроцесорна обробка, а також багатопотоковість.

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

4.2. Архітектура Linux

В ОС Linux можна виділити три основні частини:

♦ ядро, яке реалізує основні функції ОС (керування процесами, пам'яттю, вве-денням-виведенням тощо);

♦ системні бібліотеки, що визначають стандартний набір функцій для вико­ристання у застосуваннях (виконання таких функцій не потребує переходу в привілейований режим);

♦ системні утиліти (прикладні програми, які виконують спеціалізовані задачі).

Призначення ядра Linux і його особливості

Linux реалізує технологію монолітного ядра. Весь код і структури даних ядра пе­ребувають в одному адресному просторі. У ядрі можна виділити кілька функціо­нальних компонентів [63].

♦ Планувальник процесів — відповідає за реалізацію багатозадачності в системі (обробка переривань, робота з таймером, створення і завершення процесів, пе­ремикання контексту).

♦ Менеджер пам'яті — виділяє окремий адресний простір для кожного процесу і реалізує підтримку віртуальної пам'яті.

♦ Віртуальна файлова система — надає універсальний інтерфейс взаємодії з різ­ними файловими системами та пристроями введення-виведення.

♦ Драйвери пристроїв — забезпечують безпосередню роботу з периферійними пристроями. Доступ до них здійснюється через інтерфейс віртуальної фай­лової системи.

♦ Мережний інтерфейс - забезпечує доступ до реалізації мережних протоколів і драйверів мережних пристроїв.

♦ Підсистема міжпроцесової взаємодії - пропонує механізми, які дають змогу різним процесам у системі обмінюватися даними між собою.

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

Модулі ядра

Ядро Linux дає можливість на вимогу завантажувати у пам'ять і вивантажувати з неї окремі секції коду. Такі секції називають модулями ядра (kernel modules) [30] і виконують у привілейованому режимі. Модулі ядра надають низку переваг.

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

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

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

Підтримка модулів у Linux складається із трьох компонентів.

♦ Засоби керування модулями дають можливість завантажувати модулі у па­м'ять і здійснювати обмін даними між модулями та іншою частиною ядра.

♦ Засоби реєстрації драйверів дозволяють модулям повідомляти іншу частину ядра про те, що новий драйвер став доступним.

♦ Засоби розв'язання конфліктів дають змогу драйверам пристроїв резервува­ти апаратні ресурси і захищати їх від випадкового використання іншими драйверами.

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

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

Особливості системних бібліотек

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

♦ реалізацію пакувальників системних викликів;

♦ розширення функціональності системних викликів (до таких бібліотек нале­жить бібліотека введення-виведення мови С, яка реалізує на основі системних викликів такі функції, як printfO);

♦ реалізацію службових функцій режиму користувача (сортування, функції об­робки рядків тощо).

Застосування користувача

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

5. Особливості архітектури: Windows ХР

У цьому розділі ми розглянемо основні компоненти Windows ХР [14, 44],які зображені на рис. 2.4.

Базові компоненти Windows XP

Деякі компоненти Windows ХР виконуються у привілейованому режимі, інші компоненти — у режимі користувача. Ми почнемо розгляд системи з компонентів режиму ядра.

5.1. Компоненти режиму ядра

У традиційному розумінні ядро ОС містить усі компоненти привілейованого режиму, однак у Windows ХР поняття ядра закріплене тільки за одним із цих компонентів.

Рівень абстрагування від устаткування

У Windows ХР реалізовано рівень абстрагування від устаткування (у цій системі його називають HAL, hardware abstraction layer). Для різних апаратних конфігурацій фірма Microsoft або сторонні розробники можуть постачати різні реалізації HAL.

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

Ядро

Ядро Windows ХР відповідає за базові операції системи. До його основних функ­цій належать:

· перемикання контексту, збереження і відновлення стану потоків;

· планування виконання потоків;

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

Ядро Windows ХР відповідає базовим службам ОС і надає набір механізмів для реалізації політики керування ресурсами.

Основним завданням ядра є якомога ефективніше завантаження процесорів системи. Ядро постійно перебуває в пам'яті, послідовність виконання його інструкцій може порушити тільки переривання (під час виконання коду ядра багато­задачність не підтримується). Для прискорення роботи ядро ніколи не перевіряє правильність параметрів, переданих під час виклику його функцій.

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

Виконавча система

Виконавча система (ВС) Windows ХР (Windows ХР Executive) — це набір ком­понентів, відповідальних за найважливіші служби ОС (керування пам'яттю, про­цесами і потоками, введенням-виведенням тощо).

Компонентами ВС є передусім базові засоби підтримки. Ці засоби використо­вують у всій системі.

♦ Менеджер об'єктів — відповідає за розподіл ресурсів у системі, підтримуючи їхнє універсальне подання через об'єкти.

♦ Засіб локального виклику процедур (LPC) — забезпечує механізм зв'язку між процесами і підсистемами на одному комп'ютері.

Інші компоненти ВС реалізують найважливіші служби Windows ХР. Зупини­мося на деяких із них.

♦ Менеджер процесів і потоків - створює та завершує процеси і потоки, а також розподіляє для них ресурси.

♦ Менеджер віртуальної пам'яті — реалізує керування пам'яттю в системі, на­самперед підтримку віртуальної пам'яті.

♦ Менеджер введення-виведення — керує периферійними пристроями, надаючи іншим компонентам апаратно-незалежні засоби введення-виведення. Цей ме­неджер реалізує єдиний інтерфейс для драйверів пристроїв.

♦ Менеджер кеша — керує кешуванням для системи введення-виведення. Часто використовувані блоки диска тимчасово зберігаються в пам'яті, наступні опе­рації введення-виведення звертаються до цієї пам'яті, внаслідок чого підви­щується продуктивність.

♦ Менеджер конфігурації — відповідає за підтримку роботи із системним реєст­ром (registry) — ієрархічно організованим сховищем інформації про налашту­вання системи і прикладних програм.

♦ Довідковий монітор захисту - забезпечує політику безпеки на ізольованому комп'ютері, тобто захищає системні ресурси.

Драйвери пристроїв

У Windows ХР драйвери не обов'язково пов'язані з апаратними пристроями. За­стосування, якому потрібні засоби, доступні в режимі ядра, завжди варто оформ­ляти як драйвер. Це пов'язане з тим, що для зовнішніх розробників режим ядра доступний тільки з коду драйверів.

Віконна і графічна підсистеми

Віконна і графічна підсистеми відповідають за інтерфейс користувача — роботу з вікнами, елементами керування і графічним виведенням.

♦ Менеджер вікон — реалізує високорівневі функції. Він керує віконним виве­денням, обробляє введення з клавіатури або миші й передає застосуванням повідомлення користувача.

♦ Інтерфейс графічних пристроїв (Graphical Device Interface, GDI) — склада­ється з набору базових операцій графічного виведення, які не залежать від конкретного пристрою (креслення ліній, відображення тексту тощо).

♦ Драйвери графічних пристроїв (відеокарт, принтерів тощо) — відповідають за взаємодію з контролерами цих пристроїв.

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

5.2. Компоненти режиму користувача

Компоненти режиму користувача не мають прямого доступу до апаратного забез­печення, їхній код виконується в ізольованому адресному просторі. Більша части­на коду режиму користувача перебуває в динамічних бібліотеках, які у Windows називають DLL (dynamic-link libraries).

Бібліотека системного інтерфейсу

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

Підсистеми середовища

Підсистеми середовища надають застосуванням користувача доступ до служб операційної системи, реалізуючи відповідний АРІ. Ми зупинимося на двох під­системах середовища: Win32 і POSIX.

Підсистема Win32, яка реалізує Win32 АРІ, є обов'язковим компонентом Win­dows ХР. До неї входять такі компоненти:

♦ процес підсистеми Win32 (csrss.exe), що відповідає, зокрема, за реалізацію текстового (консольного) введення-виведення, створення і знищення проце­сів та потоків;

♦ бібліотеки підсистеми Win32, які надають прикладним програмам функції Win32 АРІ. Найчастіше використовують бібліотеки gdi32.dll (низькорівневі графічні функції, незалежні від пристрою), user32.dll (функції інтерфейсу ко­ристувача) і kemel32.dll (функції, реалізовані у ВС і ядрі).

Після того як застосування звернеться до функції Win32 АРІ, спочатку буде викликана відповідна функція з бібліотеки підсистеми Win32. Розглянемо ва­ріанти виконання такого виклику.

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

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

3. Функція бібліотеки підсистеми може звернутися до процесу підсистеми Win32, при цьому:

♦ коли потрібна тільки функціональність, реалізована даним процесом, пе­реходу в режим ядра не відбувається;

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

Зазначимо, що до виходу Windows NT 4.0 (1996 рік) віконна і графічна підсистеми працювали в режимі користувача як частина процесу підсистеми Win32 (тобто виклики базових графічних функцій Win32 АРІ оброблялися відповідно до варіанта 3). Надалі для підвищення продуктивності реалізацію цих підсистем було перенесено в режим ядра [14].

Підсистема POSIX працює в режимі користувача й реалізує набір функцій, ви­значених стандартом POSIX 1003.1. Оскільки застосування, або прикладні програ­ми (applications), написані для однієї підсистеми, не можуть використати функції інших, у POSIX-програмах не можна користуватися засобами Win32 АРІ (зокре­ма, графічними та мережними функціями), що знижує важливість цієї підсистем-и. Підсистема POSIX не є обов'язковим компонентом Windows ХР.

Наперед визначені системні процеси

Ряд важливих процесів користувача система запускає автоматично до закінчення завантаження. Розглянемо деякі з них.

♦ Менеджер сесій (Session Manager, smss.exe) створюється в системі першим. Він запускає інші важливі процеси (процес підсистеми Win32, процес ре­єстрації в системі тощо), а також відповідає за їхнє повторне виконання під час аварійного завершення.

♦ Процес реєстрації в системі (winlogon.exe) відповідає за допуск користувача в систему. Він відображає діалогове вікно для введення пароля, після введен­ня передає пароль у підсистему безпеки і в разі успішної його верифікації за­пускає засоби створення сесії користувача.

♦ Менеджер керування службами (Service Control Manager, services.exe) від­повідає за автоматичне виконання певних застосувань під час завантаження системи. Застосування, які будуть виконані при цьому, називають службами (services). Такі служби, як журнал подій, планувальник задач, менеджер дру­кування, постачають разом із системою. Крім того, є багато служб сторонніх розробників; так зазвичай реалізовують серверні застосування (сервери баз даних, веб-сервери тощо).

Застосування користувача

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

5.3. Об'єктна архітектура Windows ХР

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

♦ Імена об'єктів організовані в єдиний простір імен, де їх легко знаходити.

♦ Доступ до всіх об'єктів здійснюється однаково. Після створення нового об'єкта або після отримання доступу до наявного менеджер об'єктів повертає у засто­сування дескриптор об'єкта (object handle).

♦ Забезпечено захист ресурсів. Кожну спробу доступу до об'єкта розглядає під­система захисту — без неї доступ до об'єкта, а отже і до ресурсу, отримати не­можливо.

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

Об'єкти реалізовано як структури даних в адресному просторі ядра. При пере­завантаженні системи вміст усіх об'єктів губиться.

Особливості отримання доступу до об'єктів із процесів режиму користувача буде розглянуто в розділі 3.

Структура заголовка об'єкта

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

До атрибутів заголовка об'єкта належать:

♦ ім'я об'єкта і його місце у просторі імен;

♦ дескриптор захисту (визначає права, необхідні для використання об'єкта);

♦ витрата квоти (ціна відкриття дескриптора об'єкта, дає змогу регулювати кіль­кість об'єктів, які дозволено створювати);

♦ список процесів, що дістали доступ до дескрипторів об'єкта.

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

Об'єкти типу

Формат і вміст тіла об'єкта визначається його типом. Новий тип об'єктів може бу­ти визначений будь-яким компонентом ВС. Існує визначений набір типів об'єктів, які створюються під час завантаження системи (такі об'єкти, наприклад, відпові­дають процесам, відкритим файлам, пристроям вводу-виводу).

Частина характеристик об'єктів є загальними для всіх об'єктів цього типу. Для зберігання відомостей про такі характеристики використовують спеціальні об'єкти типу (type objects). У такому об'єкті, зокрема, зберігають:

♦ ім'я типу об'єкта («процес», «потік», «відкритий файл» тощо);

♦ режими доступу (залежать від типу об'єкта: наприклад, для файла такими ре­жимами можуть бути «читання» і «запис»).

Об'єкти типу недоступні в режимі користувача.

Методи об'єктів

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

♦ open — викликається при відкритті дескриптора об'єкта;

♦ close - викликається при закритті дескриптора об'єкта;

♦ delete — викликається перед вилученням об'єкта з пам'яті. Покажчики на код реалізації методів також зберігаються в об'єктах типу.

Простір імен об'єктів

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

♦ Device - імена пристроїв введення-виведення;

♦ Driver — завантажені драйвери пристроїв;

♦ ObjectTypes - об'єкти типів.

Простір імен об'єктів, як і окремі об'єкти, не зберігається після перезаванта­ження системи.

Читайте також:

1. I. Особливості аферентних і еферентних шляхів вегетативного і соматичного відділів нервової системи
2. VI.3.3. Особливості концепції Йоганна Гайнріха Песталоцці
3. VI.3.4. Особливості концепції Йоганна Фрідриха Гербарта
4. Windows
5. А. Особливості диференціації навчального процесу в школах США
6. Агітація за і проти та деякі особливості її техніки.
7. Аграрне виробництво і його особливості
8. Аграрне право як галузь права, його історичні витоки та особливості.
9. АНАТОМІЯ І ФІЗІОЛОГІЯ ЦЕНТРАЛЬНОЇ ТА ПЕРИФЕРИЧНОЇ НЕРВОВОЇ СИСТЕМИ, ЇЇ ВІКОВІ ОСОБЛИВОСТІ
10. Анатомо-фізіолгічні особливості
11. Анатомо-фізіологічна перебудова організму підлітка та її вплив на його психологічні особливості й поведінку.
12. Анатомо-фізіологічні особливості молодших школярів

Переглядів: 7055