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

:: Меню ::

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

:: Друзі ::

Карта сайту
 

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

 

 

 

 

 

Http hydraruzxpnew4af onion на сайте http://www.hydra-market.net. | Смотрите на сайте hydraruzxpnew4af union.

Завантаження самою ОС

  — Знову себе за волосся смикав
("Той самий Мюнхаузен"), Г. Горін

При завантаженні самою ОС виникає специфічна проблема: у порожній машині, швидше за все, немає програми, яка могла б це сделать.
У системах, в яких програма знаходиться в ПЗП (або іншій незалежній пам'яті) цієї проблеми не існує: при включенні живлення програма в пам'яті вже є і відразу починає іспблняться. При включенні живлення або апаратному скиданні процесор виконує команду, що знаходиться за певною адресою, наприклад, OXFFFFFFFA. Якщо там знаходиться ПЗП, а в нім записана програма, вона і починає виконуватися.
При розробці програм для вбудовуваних застосувань часто використовуються внутрішньосхемні імітатори ПЗП, доступні цільовій системі як ПЗП, а системі розробника — як ОЗУ або спеціальний зовнішній пристрій.
Комп'ютери спільного призначення також не можуть обійтися без ПЗП. Програма, записана в нім, називається завантажувальним монітором . Стартова точка цієї програми повинна знаходитися якраз за тією адресою, по якій процесор передає управління у момент включення живлення. Ця програма проводить первинну ініціалізацію процесора, тестування пам'яті і обов'язкового периферійного устаткування, і, нарешті, починає завантаження системи. У комп'ютерах, сумісних з IBM РС, завантажувальний монітор відомий як BIOS.
На багатьох системах в ПЗП буває прошито щось більше, ніж первинний завантажувач. Це може бути ціла контрольно-діагностична система, звана консольним монітором . Така система є на всіх машинах лінії Pdp-11/vax і на VME-системах, розрахованих на Os-9 або Vxworks. Такий монітор дозволяє вам переглядати вміст пам'яті за заданою адресою, записувати туди дані, запускати якусь область пам'яті як програму і багато що інше. Він же дозволяє вибирати пристрій, з якого проводитиметься подальше завантаження. У Pdp-11/vax на такому моніторі можна писати програми, майже з таким же успіхом, як на асемблері. Потрібно лише уміти лічити про себе у вісімковій системі числення. іа машинах фірми Sun як консольний монітор використовується інтерпретатор мови Forth. На ранніх моделях IBM РС в ПЗП був прошитий щтерпретатор BASIC. Саме тому клони IBM РС мають величезне ко-чичество погано використовуваного адресного простору вище сегменту ОХСООО. Ви можете переконатися в тому, що BASIC там має бути, викликавши з програми переривання 0x60. Ви отримаєте на моніторі повідомлення начеб: NO
ROM BASIC, PRESS ANY KEY TO REBOOT
. Вообщеговоря, цей BASIC не є консольним монітором в строгому сенсі цього слова, оскільки отримує управління не перед завантаженням, а лише після того, як завантаження зі всіх пристроїв завершилося невдачею.
Після запуску консольного монітора і ініціалізації системи ви можете наказати системі почати власне завантаження ОС. На IBM РС такий наказ віддається автоматично, і часто завантаження проводиться зовсім не з того пристрою, з якого хотілося б. На цьому і заснований життєвий цикл завантажувальних вірусів.
Щоб завантажувальний монітор зміг що б то не було завантажити, він повинен уміти проїніциалізіровать пристрій, з якого передбачається завантаження, і рахувати з нього завантажуваний код. Тому завантажувальний монітор зобов'язаний містити модуль, здатний управляти завантажувальним пристроєм. Наприклад, типовий BIOS Рс-совместімого комп'ютера містить модулі управління гнучким диском і жорстким диском з інтерфейсом Seagate 506 (у сучасних комп'ютерах це звичайно інтерфейс EIDE, що відрізняється від Seagate 506 конструктивом, але програмно сумісний з ним зверху вниз).
Крім того, конструктіви багатьох систем допускають установку ПЗП на платах контроллерів додаткових пристроїв. Цей ПЗП повинен містити програмний модуль, здатний проїніциалізіровать пристрій і провести завантаження з нього (мал. 3.15).

Мал. 3.15. Системний ПЗП і BIOS дискового контроллера

Як правило, сервіси завантажувального монітора доступні завантажуваній системі. Так, модуль управління дисками BIOS Рс-совместімих комп'ютерів надає функції прочитування і запису окремих секторів диска Доступ до функцій ПЗП дозволяє значно скоротити код первинного завантажувача ОС, і, нерідко, сделать його незалежним від пристрою.
Найпростіше відбувається завантаження з різних послідовних пристроїв — стрічок, перфострічок, магнітофонів, перфокарточних считивателей і так далі Завантажувальний монітор прочитує в пам'ять все, що можна рахувати із заданого пристрою і передає управління на початок тієї інформації яку прочитав.
У сучасних системах таке завантаження практично не використовується. У них завантаження відбувається з пристроїв з довільним доступом, як правило — з дисків. При цьому зазвичай в пам'ять прочитується нульовий сектор нульової доріжки диска. Вміст цього сектора називають первинним завантажувачем. У IBM РС цей завантажувач називають завантажувальним сектором або boot-сектором.
Як правило, первинний завантажувач, користуючись сервісами завантажувального монітора, шукає на диску початок файлової системи своєї рідної ОС, знаходить в цій файловій системі файл з певним ім'ям, прочитує його в пам'ять і передає цьому файлу управління. У простому випадку такий файл і є ядром операційної системи.
Розмір первинного завантажувача обмежений найчастіше розміром сектора на диску, тобто 512 байтами. Якщо файлова система має складну структуру, інколи первинному завантажувачу доводиться прочитувати вторинний розмір якого може бути набагато більше. Із-за більшого розміру цей завантажувач набагато розумніше і в змозі знатися на структурах файлової системи. В деяких випадках використовуються і третинні завантажувачі.
Це послідовного виконання завантажувачів зростаючої складності, що втягують один одного, називається бутстрапом (bootstrap) що можна перевести як "втягування [себе] за шнурки від черевик".
Велику практичну роль грає ще один спосіб завантаження — завантаження по мережі. Вона відбувається аналогічно завантаженню з диска: ПЗП, встановлений на мережевій карті, посилає в мережу пакет стандартного вмісту, який містить запит до сервера видаленого завантаження. Цей сервер передає по мережі вторинний завантажувач і так далі Така технологія незамінна при завантаженні бездіськових робочих станцій. Централізоване розміщення завантажувальних образів робочих станцій на сервері спрощує управління ними, захищає налаштування ОС від випадкових і зловмисних модифікацій і істотно здешевлює експлуатацію великих парків настільних комп'ютерів, тому по мережі нерідко завантажуються і машини, що мають жорсткий диск.
Найпростіше відбувається завантаження систем, ядро яких разом зі всіма додатковими модулями (драйверами пристроїв, файлових систем і ін.)
Зібрано в єдиний завантажувальний модуль. Наприклад, в системах сімейства Unix, ядро так і називається /unix (у FREEBSD - /vmunix, в Linux -/vnilinux, плі, і випадку упакованого ядра, /vmlinuz).
При переконфігурації системи, додаванні або видаленні драйверів і інших модулів необхідна пересборка ядра, яка може проводитися або стандартним системним редактором зв'язків, або спеціальними утилітами генерації системи. Для такої пересборки в постачання системи повинні входити або вихідні тексти (як в Linux і BSD), або об'єктні модулі ядра. Збірка ядра з об'єктних модулів на сучасних системах займає не більше декількох хвилин. Повна перекомпіляція ядра з вихідних текстів, звичайно, продовжується істотно довше.
На випадок, якщо системний адміністратор помилиться і збере непрацездатне ядро, вторинний завантажувач таких систем часто надає можливість вибрати файл, який слід завантажити. Ядро таких систем зазвичай не використовує жодних конфігураційних файлів — всі налаштування також задаються при генерації.
Більшість сучасних ОС використовують складнішу форму завантаження, при якому додаткові модулі підвантажуються вже після старту самого ядра. В термінах попередніх розділів це називається "Збірка у момент завантаження". Список модулів, які необхідно завантажити,, а також параметри налаштування ядра зібрані в спеціальному файлі або декількох файлах. В DOS і Os/2 цей файл називається CONFIG.SYS, в Win32-cncrem -рєєстром (registry).
Складність при такому способі завантаження полягає в тому, що ядро, ще повністю не проїшщиалізовавшись, вже має бути здатне працювати з файловою системою, знаходити в ній файли і прочитувати їх в пам'ять.
Особливо складений цей спосіб тоді, коли драйвери завантажувального диска і завантажувальної файлової системи самі є підвантажуваними модулями. Зазвичай при цьому ядро користується функціями роботи з файловою системою, що надаються вторинним (або третинним, загалом, останнім по порядку) завантажувачем, до тих пір, поки не проїніциалізіруєт власні модулі. Вторинний завантажувач зобов'язаний уміти читати завантажувальні файли, інакше він не зміг би знайти ядро. Якщо постачальники ОС не спромоглися написати відповідний вторинний завантажувач, а надали лише драйвер файлової системи, ОС зможе працювати з такою файловою системою, але не зможе з неї завантажуватися.
Деякі системи, наприклад DOS, можуть вантажитися лише з пристроїв, підтримуваних BIOS, і лише з одного типа файлової системи — FAT, Драйвер якої ськомпонован з ядром. Цікавий розвиток цієї ідеї представляє Linux, модулі якого можуть приєднуватися до ядра як статично, так і динамічно. Динамічно можуть підвантажуватися будь-які модулі, окрім драйверів завантажувального диска і завантажувальною ФС.
Переваги, які дає динамічно збиране у момент завантаження ядро, не так вже великі в порівнянні з системами, в яких ядро збирається статично. Втім, ряд сучасних систем (Solaris, Linux, Netware) йдуть в цьому напрямі далі і дозволяють підвантажувати модулі вже після завантаження і навіть вивантажувати їх. Така архітектура пред'являє певні вимоги до інтерфейсу модуля ядра (він повинен уміти не лише ініціалізувати сам себе і, якщо це необхідно, керований ним пристрій, н0 і коректно визволяти всі зайняті ним ресурси при вивантаженні), але дає значні переваги.
По-перше, це допускає підвантаження модулів за запитом. При цьому підсистеми, потрібні лише інколи, можуть не завантажитися взагалі. Навіть ті модулі, які потрібні завжди, можуть проїніциалізіроваться, лише коли стануть потрібні, зменшивши тим самим час від початку завантаження до старту деяких сервісів. Друге, подаруй навіть важливіше для системного адміністратора, перевага полягає в можливості реконфігурувати систему без перезавантаження, що особливо корисно для систем колективного користування. І, нарешті, можливість вивантаження модулів ядра інколи (але не завжди, а лише якщо поломка не заважає драйверу коректно визволити ресурси) дозволяє коректувати роботу окремих підсистем — знову-таки без перезавантаження всієї ОС і призначених для користувача застосувань.
Опинившись в пам'яті і, так або інакше, підтягнувши всі необхідні додаткові модулі, ядро запускає їх підпрограми ініціалізації. При динамічному підвантаженні ініціалізація модулів часто відбувається у міру їх завантаження. Зазвичай ініціалізація ядра завершується тим, що воно завантажує певну програму, яка продовжує ініціалізацію, — вже не ядра, але системи в цілому.
Так, системи сімейства UNIX мають спеціальну програму ініціалізації, яка так і називається, — init. Ця програма запускає різні процеси-демони, наприклад cron — програму, яка уміє запускати інші задані нею програми в задані моменти часу, різні мережеві сервіси, програми, які чекають введення з термінальних пристроїв (getty), і так далі Набор програм, що запускаються, задається у файлі /etc/inittab (у різних версіях системи цей файл може мати різні імена, /etc/inittab використовується в System V). Адміністратор системи може редагувати цей файл і встановлювати ті сервіси, які в даний момент потрібні, позбавлятися від тих, які не потрібні, і так далі
Програма init залишається запущеної весь час роботи системи. Вона, як правило, стежить за подальшою долею запущених нею процесів. Залежно від заданих у файлі /etc/inittab параметрів, вона може або перезапускати процес після його завершення, або не робити цього.
Аналогічний сервіс ініціалізації в тій або іншій формі надають всі сучасні операційні системи.

Завантаження Sun Solaris
Повний цикл завантаження Solaris (версія Unix System V Release 4, що поставляється фірмою Sun) на комп'ютерах х86 відбувається в шість етапів. Перші три етапи стандартні для всіх ОС, що працюють на IBM Рс-совместімой техніці. При включенні комп'ютера запускається прошитий в ПЗП BIOS. Він проводить тестування процесора і пам'яті і ініціалізацію машини. В процесі ініціалізації BIOS встановлює обробник переривання int I3h. Цей обробник уміє прочитувати і записувати окремі сектори жорстких і гнучких дисків і проводити деякі інші операції над дисковими пристроями. Первинні завантажувачі ОС зазвичай користуються цим сервісом. Деякі ОС, наприклад Ms/dr DOS, використовують цей сервіс не лише при завантаженні, але і при роботі, і, завдяки цьому, можуть не мати власного модуля управління дисками.
Якщо завантаження відбувається з жорсткого диска, BIOS завантажує в пам'ять і запускає нульовий сектор нульової доріжки диска. Цей сектор зазвичай містить не первинний завантажувач операційної системи, а MBR (Master Boot Record — головний завантажувальний запис). Ця програма забезпечує розбиття фізичного жорсткого диска на декілька логічних розділів (partition) і можливість поперемінного завантаження різних ОС, встановлених в цих розділах (мал. 3.16).

Мал. 3.16. Master Boot Record і таблиця розділів

Розбиття фізичного диска на логічних програма MBR здійснює на основі таблиці розділів (partition table), що міститься в її телі, яка містить кордони і типів розділів. MBR перехоплює переривання int 13^ і транслює звернення до дискової підсистеми так, що звернення до логічного диска N перетворяться в звернення до N-ному розділу фізичного диска
Один з розділів диска має бути помічений як активний або завантажувальний. MBR завантажує початковий сектор цього розділу — звичайно це і є первинний загру3. чик ОС. Багато реалізацій MBR, у тому числі і що поставляється з Solaris, можуть надавати користувачеві вибір розділу, з якого слід починати завантаження Вибір зазвичай надається у формі паузи, протягом якої користувач може натискувати якусь клавішу або комбінацію клавіш. Якщо нічого не натискуватиме, почнеться завантаження з поточного активного розділу.
Так або інакше, але завантажувальний сектор — за сумісництвом, первинний завантажувач Solaris опиняється в пам'яті і починає виконуватися. Виконання його полягає в тому, що він завантажує — ні, ще не ядро, а спеціальну програму, звану DCU (Device Configuration Utility, утиліта конфігурації пристроїв). Основне призначення цієї програми — імітація сервісів консольного монітора комп'ютерів фірми Sun на основі процесорів SPARC.
DCU проводить ідентифікацію встановленого в машині устаткування. Користувач може втрутитися в цей процес і, наприклад, вказати системі, що такого-то пристрою в конфігурації немає, навіть якщо фізично воно і присутнє, або встановити драйвери для нового типа пристроїв. Драйвери, використовувані DCU, відрізняються від драйверів, використовуваних самим Solaris, називаються вони BEF (Boot Executable File), і починають виконання, як і сама DCU, в.реальном режимі процесора х86. .
Знайшовши все необхідне устаткування, DCU запускає вторинний завантажувач Solaris. Логічний диск, виділений Solaris, має внутрішню структуру і також розбитий на декілька розділів (мал. 3.17). Щоб не плутати ці розділи з розділами, створюваними MBR, їх називають слайсамі (slice). Завантажувальний диск Solaris повинен мати мінімум два слайса — Root (коренева файлова система) і Boot, в якому і розміщуються вторинний завантажувач і DCU.
Вторинний завантажувач, користуючись BEF-модулем завантажувального диска для доступу до цього диска, прочитує таблицю слайсов і знаходить кореневу файлову систему. У цій файловій системі він вибирає файл /kernel/unix, який і є ядром Solaris. Насправді, вторинний завантажувач виконує командний файл, в якому можуть бути присутніми умовні оператори, і, залежно від тих або інших умов, як ядро можуть бути використані різні файли, /kernel/unix використовується за умовчанням.
Крім того, користувачеві надається пауза (за умовчанням 5 секунд), протягом якої він може перервати завантаження за умовчанням і наказати завантажити якийсь інший файл, або той же файл, але з іншими параметрами.
Будучи так чи інакше завантажено, ядро, користуючись сервісами вторинного завантажувача, прочитує файл /etc/system, в якому вказані параметри налаштування системи. Потім, користуючись інформацією, наданою DCU, ядро формує дерево пристроїв — список встановленого в системі устаткування, і відповідно до цього списку починає підвантажувати модулі, керівники устройствамі— драйвери. Підвантаження як і раніше відбувається за допомогою сервісів вторинного завантажувача — адже всі драйвери розміщені на завантажувальному диску і в кореневій файловій системі, у тому числі і драйвери самого цього диска і цієї файлової системи.

Мал. 3.17. Структура розділу Solaris

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

Існують ОС, які не уміють самостійно виконувати весь цикл бутстрапа. Вони використовують примітивнішу операційну систему, яка виконує їх вторинний (або який це вже буде по рахунку) завантажувач, і допомагає цьому завантажувачу помістити в пам'ять ядро ОС. На процесорах х8б як стартова система часто використовується Ms/dr DOS, а завантажувач нової ОС оформляється у вигляді ЕХЕ-файла.
Таким чином влаштовані системи MS Windows l.x-З.х, Windows 95/98/me, Desqview і ряд інших "многозадачников" для MS DOS. Так само завантажується сервер Nowell Netware, система Oberon для х86, програми, написані для різних розширювачів DOS (DOS extenders) і так далі Багато З перерахованих систем, наприклад Windows (версії молодше З.11 — в обов'язковому порядку, а З.11 і 95/98/ме лише в певних конфігураціях) використовують DOS і під час праці дисковою підсистемою. Проте, ці програмні пакети уміють самостійно завантажувати Призначені для користувача програми і виконувати всі перераховані у введенні Функції і повинні, відповідно до нашого визначення, вважатися повноцінними операційними системами.

 

:: Реклама ::

 

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


 

 

 


Copyright © Kivik, 2017