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

:: Меню ::

Головна
Представлення даних в обчислювальних системах
Машинні мови
Завантаження програм
Управління оперативною пам'яттю
Сегментна і сторінкова віртуальна пам'ять
Комп'ютер і зовнішні події
Паралелізм з точки зору програміста
Реалізація багатозадачності на однопроцесорних комп'ютерах  
Зовнішні пристрої
Драйвери зовнішніх пристроїв
Файлові системи
Безпека
Огляд архітектури сучасних ОС

:: Друзі ::

Карта сайту
 

:: Статистика ::

 

 

 

 

 

Системи з базовою віртуальною адресацією

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

Мал. 4.18. Віртуальна пам'ять на основі базової адресації

Ви можете відмітити, що термін базова адресація вже зайнятий — ми називали таким чином адресацію за схемою reg[offset]. Метод, про який зараз йде мова, полягає у формуванні адреси за тією ж схемою. Відзнака полягає в тому, що регістр, відносно якого відбувається адресація, не доступний прикладній програмі. Крім того, його значення додається До всіх адрес, у тому числі до "абсолютних" адресних заслань або змінних типа покажчик. По суті, така адресація є способом організації віртуального адресного простору.
правило, машини, що використовують базову адресацію, мають два регістри. Один з регістрів задає базу для адрес, другою встановлює верхню межу. У системі Iсl900/одренок ці регістри називаються відповідно BASE і DATUM. Якщо адреса виходить за кордон, встановлений значенням DATUM виникає виняткова ситуація (exception) помилкової адресації. Як правило, це приводить до того, що система примусово завершує роботу програми.
За допомогою цих двох регістрів ми відразу вирішуємо дві важливі проблеми.
По-перше, ми можемо ізолювати процеси один від одного — помилки в програмі одного процесу не приводять до руйнування або пошкодження образів інших процесів або самої системи. Завдяки цьому ми можемо забезпечити захист системи не лише від помилкових програм, але і від зловмисних дій користувачів, направлених на руйнування системи або доступ до чужих даних.
По-друге, ми дістаємо можливість пересувати образи процесів по фізичній пам'яті так, що програма кожного з них не помічає переміщення. За рахунок цього ми вирішуємо проблему фрагментації пам'яті і даємо процесам можливість нарощувати свій адресний простір. Дійсно, в системі з відкритою пам'яттю процес може додавати собі пам'ять лише до тих пір, поки не дістанеться до початку образу наступного процесу. Після цього ми повинні або говорити про те, що пам'яті немає, або миритися з тим, що процес може займати несуміжні області фізичного адресного простору. Друге рішення різко ускладнює управління пам'яттю як з боку системи, так і з боку процесу, і часто виявляється неприйнятним (детальніше пов'язані з цим проблеми обговорюються в разд. Відкрита пам'ять (продовження)). У разі ж базової адресації ми можемо просто зрушити образ, що заважає нам, вгору по фізичних адресах (мал. 4.19).

Мал. 4.19. Дефрагментація при використанні базової адресації

Часто ОС, що працюють на такій архітектурі, уміють скидати на диск образи тих процесів, які довго не отримують управління. Це найпростіша з форм своппінга (swapping— обмін) (російськомовний термін "сторінковий обмін" досить широко поширений, але в даному випадку його використання було б невірним, бо обміну піддаються не сторінки, а цілком завдання).
вирішивши перераховані вище проблеми, ми створюємо інші, досить неочікувані. Ми звели наклеп, що базовий регістр недоступний прикладним завданням. Але якомусь завданню він має бути доступний! Яким же чином процесор взнає, чи виконує він системне або прикладне завдання, і чи не зможе зловмисна прикладна програма його переконати в тому, що є системною?
Інша проблема полягає в тому, що, якщо ми хочемо надати прикладним програмам можливість викликати систему і передавати їй параметри, ми повинні забезпечити процеси (як системні, так і прикладні) тими або іншими механізмами доступу до адресних просторів один одного.
Насправді, ці дві проблеми тісно взаємозв'язані — наприклад, якщо ми надамо прикладній програмі вільний доступ до системного адресного простору, нам доведеться розпрощатися з будь-якими надіями на захист від зловмисних дій користувачів. Раз проблеми взаємозв'язані, то і вирішувати їх слід в комплексі.
Стандартне вирішення цього комплексу проблем полягає в наступному. Ми забезпечуємо процесор прапором, який вказує, виконується системний або призначений для користувача процес. Код призначеного для користувача процесу не може маніпулювати цим прапором, проте йому доступна спеціальна команда. У різній архітектурі ці спеціальні команди мають різні мнемонічні позначення, далі ми називатимемо цю команду SYSCALL. SYSCALL одночасно перемикає прапор в положення "системний" і передає управління на певну адресу в системному адресному просторі. Процедура, що знаходиться за цією адресою, називається диспетчером системних викликів (мал. 4.20).
Повернення з системного виклику здійснюється іншою спеціальною командою, назвемо її SYSRET. Ця команда передає управління на вказану адресу у вказаному адресному просторі і одночасно переводить прапор в достаток "користувач". Необхідність виконувати ці дві операції однією командою очевидна: якщо ми спочатку скинемо прапор, ми втратимо можливість перемикати адресні простори, а якщо ми спочатку передамо управління, ніхто не може нам гарантувати, що призначений для користувача код добровільно вийде з системного режиму.

Мал. 4.20. Диспетчер системних викликів

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

Мал. 4.21. Системний і призначений для користувача режими


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


:: Реклама ::

купить ткань лакоста, лакоста ткань купить оптом

 

:: Посилання ::


 

 

 


Copyright © Kivik, 2017