ЗМІСТ
| ВСТУП | |
| I. ІНСТРУМЕНТИ. ПРИЛАДИ ДЛЯ ВИКОНАННЯ РОБОТИ. | |
| ІІ. ОРГАНІЗАЦІЯ РОБОЧОГО МІСЦЯ ПРИ ВИКОНАННІ РОБОТИ. | |
| ІІІ. ТЕХНОЛОГІЧНІ ПРИНЦИПИ РОБОТИ ОПЕРАЦІЙНИХ СИСТЕМ. | |
| 3.1. Загальні відомості про ОС | |
| 3.1.1. Основні концепції розроблення операційних систем. Відмінності ОС. | |
| 3.1.2. Ядро. Завантажувач. Комбінація різних підходів. | |
| 3.2. Компілятор і інтерпретатор | |
| 3.2.1. Історія створення | |
| 3.2.2. Принципи та базис роботи компілятора і інтерпретатора | |
| 3.2.3. Особливості управління пам’яттю в різних мовах програмування, “Garbage Collector”. + | |
| 3.3. Залізо. Low level. | |
| 3.3.1. Фізичні функції і особливості транзисторів | |
| 3.3.2. Історія розвитку процесорів. | |
| 3.3.3. Драйвери. | |
| 3.3.4. Ввід/вивід | |
| 3.3.5 “Шини” вводу/виводу | |
| 3.3.6. Доступ до пам’яті | |
| 3.3.7. MIPS/RISC | |
| 3.3.8. Багатопроцесорна обробка | |
| IV. НОРМИ ВИРОБІТКУ І ЧАСУ НА ВИКОНАННЯ РОБОТИ | |
| V. ОХОРОНА ПРАЦІ ТА БЕЗПЕКА ЖИТТЄДІЯЛЬНОСТІ | |
| ВИСНОВОК | |
| СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ | |
ВСТУП
I. ІНСТРУМЕНТИ. ПРИЛАДИ ДЛЯ ВИКОНАННЯ РОБОТИ.
ІІ. ОРГАНІЗАЦІЯ РОБОЧОГО МІСЦЯ ПРИ ВИКОНАННІ РОБОТИ.
ІІІ. ТЕХНОЛОГІЧНІ ПРИНЦИПИ РОБОТИ ОПЕРАЦІЙНИХ СИСТЕМ.
3.1. Загальні відомості про ОС
3.1.1. Основні концепції розроблення Операційних систем. Відмінності ОС. Ядра.
На сьогоднішній день існують багато різних операційних систем, які відрізняються не так сильно як може здаватись на перший погляд звичайному юзеру, тому що – концепція по якій будують операційні системи, просто фізично не може відрізнятись в кожній окремій ОС.
Вимоги, що були пред’явленні до операційних систем ще в 90-тих роках звучать так:
Можливість розширення. Код повинен бути написаний таким чином, щоб можна було легко ввести доповнення і зміни, коли і якщо це буде потрібно, і не порушити цілісність системи.
Переносимість. Код повинен легко переноситися з процесору одного типу(CISC, RISC) на процесор іншого типу(ARM) і з апаратної платформи (яка включає поряд з типом процесора і спосіб організації всієї апаратури комп'ютера) одного типу на апаратну платформу іншого типу.
Надійність і відмово стійкість. Система повинна бути захищена як від внутрішніх, так і від зовнішніх помилок, збоїв та відмов. Її дії повинні бути завжди передбачуваними, а додатки не повинні бути в змозі завдавати шкоди ОС.
Сумісність. Операційна система повинна мати засоби для виконання прикладних програм, написаних для інших операційних систем. Крім того, призначений для користувача інтерфейс повинен бути сумісний з існуючими системами і стандартами.
Безпека. ОС повинна мати засоби захисту ресурсів одних користувачів від інших.
3.1.2. Можливість розширення.
У той час, як апаратна частина комп’ютера застаріває за кілька років, користь операційних систем може вимірюватися десятиліттями. Прикладом може служити ОС UNIX. Тому операційні системи завжди еволюційно зміються з часом, і ці зміни більш значущі, ніж зміни апаратних засобів. Зміни ОС зазвичай є придбання нею нових властивостей.
Наприклад, підтримка нових пристроїв, таких як CD-ROM, можливість зв’язку з мережами нового типу, підтримка перспективних технологій, таких як графічний інтерес користувача або об’єктно-орієнтоване програмне оточення, використання більш ніж одного процесора і так далі.
Можливість розширення може досягатися за рахунок модульної структури ОС, при якій програми будуються з набору окремих модулів, взаємодіючих тільки через функціональний інтерфейс.
Нові компоненти можуть бути додані в операційну систему модульним шляхом, вони виконують свою роботу, використовуючи інтерфейси, підтримувані існуючими компонентами.
Використання об’єктів для подання системних ресурсів також покращує розширюваність системи. Об’єкти – це абстрактні типи даних, над якими можна проводити тільки ті дії, які передбачені спеціальним набором об’єктних функцій. Об’єкти дозволяють одноманітно управляти системними ресурсами. Додавання нових об’єктів не руйнує існуючу ієрархію об’єктів і не вимагає змін існуючого коду.
Прекрасні можливості для розширення надає підхід до структурування операційної системи по типу клієнт-сервер з використанням мікро ядерної технології. Відповідно до цього підходу операційна система будується як сукупність привілейованої керуючої програми і набору непривілейованих послуг-серверів. Основна частина ОС може залишатися незмінною, в той час, як можуть бути додані нові сервери, або поліпшені старі.
Переносимість
Вимога переносимості коду тісно пов’язана з розширюваністю. Можливість розширення дозволяє поліпшувати операційну систему, в той час як переносимість дає можливість переміщати всю систему на машину, що базується на іншому процесорі або апаратній платформі, роблячи при цьому по можливості невеликі зміни в коді. Хоча ОС часто описують як open source(відкритий код; переносимі), або як closed(закриті; не переносимі), переносимість – це не бінарний стан. Питання не в тому, чи система може бути перенесена, а в тому, наскільки легко це можна зробити. Щоб зробити переносиму ОС потрібно слідувати деяким правилам:
По-перше, більша частина коду повинна бути написана на мові яка підтримується на всіх машинах, куди ви хочете переносити систему. Зазвичай це означає, що код повинен бути написаний на мові високого рівня і переважно стандартизованому, наприклад на мові С.
Програма, написана на асемблері, не є переносимою, виключно тільки якщо у вас дві одинакові, або схожі за командами(ISA) машини.
По-друге, слід враховувати, в яке фізичне оточення програма повинна бути перенесена. Різна апаратура вимагає різних рішень при створенні ОС. Наприклад, ОС, побудована на 32-бітових адресах, не може бути перенесена на машину зв 16-бітовими адресами без труднощів. А переписувати 40к+ коду ніхто не збирається.
По-третє, важливо мінімізувати або, якщо можливо, виключити ті частини коду, які безпосередньо взаємодіють за апаратними засобами. Залежність від апаратури може мати багато форм. Деякі очевидні форми залежності включають пряме маніпулювання регістрами й іншими апаратними засобами, що не є добре і погано впливає на захист від зовнішньої загрози і кривих рук юзера.
По-четверте, якщо апаратно залежний код не може бути повністю виключений, то він повинен бути ізольований в декількох добре локалізуємих модулях. Апаратно-залежний код не повинен бути розподілений по всій системі. Наприклад, можна заховати апаратно-залежну структуру в абстрактного типу. Інші модулі системи будуть працювати з цими даними, а не з апаратурою, використовуючи набір деяких функцій. Коли ОС переноситься, то змінюються тільки ці дані і функції, які ними маніпулюють.
Для легкого перенесення ОС при її розробці повинні бути дотримані наступні вимоги:
Мова високого рівня. Більшість ОС написано на мові С (стандарт ANSI X3. 159-1989). Інженери вибирають С тому, що він стандартизований, і тому, що С-компілятори широко доступні. Асемблер використовується тільки для тих частин системи, які повинні безпосередньо взаємодіяти з апаратурою (наприклад, обробник переривань) або для частин, які вимагають максимальної швидкості (наприклад цілочислова арифметика підвищеної точності). Однак непереносимий код повинен бути ретельно ізольований всередині тих компонентів, де він використовується.
Ізоляція процесора. Деякі низько рівневі частини ОС повинні мати доступ до процесорно-залежним структурам даних і регістрів. Однак код, який робить це, повинен міститися в невеликих модулях, які можуть бути замінені аналогічними модулями для інших процесорів.
Ізоляція платформи. Залежність від платформи полягає в розбіжностях між робочими станціями різних виробників, побудованими на одному і тому ж процесорі (наприклад, MIPS R4000). Необхідно запровадити програмний рівень, котрий абстрагує апаратний рівень (кеш, контролери переривань вводу-виводу і т.п.) Разом із шаром низькорівневих програм таким чином, щоб високорівневий код не потребував змін при перенесенні з одної платформи на іншу.
Надійність і відмовостійкість
Відмостійкість ОС – здатність операційної системи відновлювати свою працездатність після збоїв як програмного, так і апаратного характеру.
В ідеалі користувач взагалі не повинен спостерігати ніяких негативних наслідків збоїв в роботі операційної системи. Збої програмного характеру можуть виникати з різних причин:
Вірусна атака
Необережне поводження з системними файлами
Конфлікт драйверів пристроїв
і т.д.
Відмовостійкість
Апаратні збої можуть виникати через недотримання умов експлуатації обладнання, через некоректний монтаж плат на систему плату.
Для кожної категорії причин виникнення програмних збоїв існують методи їх запобігання. Частина методів включається в керівництво по операційним системам у вигляді обов’язкових рекомендацій. Наприклад, в керівництві будь-якої ОС перераховуються файли і папки, видалення яких привиде до серйозних порушень в роботі операційної системи. Більша ж частина методів реалізується у вигляді спеціалізованих програмних комплексів. Наприклад, засоби захисту від вірусних і мережевих атак, механізм блокування доступу до системних файлів, механізми збереження стану системи.
На жаль, не існую настільки ж надійних методів запобігання апаратних збоїв, як у випадку з програмними збоями. Якщо в разі вірусної атаки операційну систему можна відновити з заздалегідь збереженого образу системи, то в разі заміни будь-якого компонента може знадобитися переустановлення операційної системи. А якщо вийде з ладу носій даних, то можна втратити важливу інформацію. Найчастіше неможливо навіть передбачити виникнення апаратного збою і його наслідки, в той час я к програмні збої порівняно легко прогнозуються і їх можна уникнути.
Для того щоб не виникали апаратні збої, необхідно дотримуватися умов експлуатації апаратних компонентів комп’ютера. Наприклад, спроба розбору жорсткого диска призведе до незворотних ушкоджень і гарантованої втрати інформації.
Будь-яка операційна система містить програми, що запобігають більшість стандартних збоїв, в тому числі і засоби моніторингу стану апаратних компонентів, але для запобігання збоїв, що виникають унаслідок навмисних дій користувачів, необхідно встановлювати додаткове програмне забезпечення. Наприклад, для відображення мережевих атак необхідна наявність в системі мережевого екрану, а для захисту від вірусних впливів - комплекс антивірусного захисту.
Захист ресурсів
Кожна операційна система повинна забезпечувати певний рівень захищеності - як ресурсів, так і даних користувачів. Дані користувачів захищаються використанням механізму авторизації і розмежування прав доступу. Безпека даних користувачів операційних систем регламентується стандартом безпеки, розглянутим раніше.
Захист ресурсів одних процесів від захоплення іншими процесами організувати не так складно, як захист даних користувачів, оскільки, хоча процеси і мають більшу свободу дій, ніж більшість користувачів, в той же час процес не має волю і здатний виконувати тільки ті дії, на які запрограмований. Тому питання захисту ресурсів від захоплення вирішуються в рамках завдання планування ресурсів.
Захист даних
Операційні системи включають в себе механізм авторизації доступу. Традиційно користувач повинен мати обліковий запис в операційній системі тієї машини, на якій працює, щоб мати можливість використовувати машину для вирішення своїх завдань. Якщо машини об'єднані в локальну мережу, то обліковий запис може зберігатися не на самій машині, а на сервері мережі.
У разі коли профілі користувачів зберігаються на сервері, отримати несанкціонований доступ до даних істотно складніше, ніж якби профілі зберігалися на конкретних машинах, оскільки сервери мережі забезпечені набагато більш крипостійкість механізмом захисту даних, ніж робочі станції.
Проблема захисту даних користувачів від несанкціонованого доступу також може вирішуватися і самим користувачем. Існує ряд програмних продуктів, що дозволяють користувачам закривати доступ до своїх даних таким чином, що для читання їх на цій же машині необхідно знати пароль, а для злому і отримання доступу в обхід системи захисту - принцип кодування даних.
Ці програмні продукти використовують такі алгоритми кодування даних, що спроба злому захисту може розтягнутися на кілька років.
Сумісність
Одним з аспектів сумісності є здатність ОС виконувати програми, написані для інших ОС або для більш ранніх версій даної операційної системи, а також для іншої апаратної платформи.
Необхідно розділяти питання двійковій сумісності і сумісності на рівні вихідних текстів програм. Двійкова сумісність досягається в тому випадку, коли можна взяти виконувану програму і запустити її на виконання на інший ОС. Для цього необхідні: сумісність на рівні команд процесора, сумісність на рівні системних викликів і навіть на рівні бібліотечних викликів, якщо вони є динамічно зв'язуваними.
Сумісність на рівні вихідних текстів вимагає наявності відповідного компілятора в складі програмного забезпечення, а також сумісності на рівні бібліотек і системних викликів. При цьому необхідна перекомпіляція наявних вихідних текстів в новий виконуваний модуль.
Сумісність на рівні вихідних текстів важлива в основному для розробників додатків, в розпорядженні яких ці вихідні тексти завжди є. Але для кінцевих користувачів практичне значення має тільки двійкова сумісність, так як тільки в цьому випадку вони можуть використовувати один і той же комерційний продукт, що поставляється у вигляді довічного виконуваного коду, в різних операційних середовищах і на різних машинах.
Чи володіє нова ОС двійковій сумісністю або сумісністю вихідних текстів з існуючими системами, залежить від багатьох чинників. Найголовніший з них - архітектура процесора, на якому працює нова ОС. Якщо процесор, на який переноситься ОС, використовує той же набір команд (можливо з деякими доповненнями) і той же діапазон адрес, тоді двійкова сумісність може бути досягнута досить просто.
Набагато складніше досягти двійковій сумісності між процесорами, заснованими на різних архітектурах. Для того, щоб один комп'ютер виконував програми іншого (наприклад, DOS-програму на Mac), цей комп'ютер повинен працювати з машинними командами, які йому спочатку незрозумілі. Наприклад, процесор типу 680x0 на Mac повинен виконувати двійковий код, призначений для процесора 80x86 в PC. Процесор 80x86 має свої власні дешифратор команд, регістри і внутрішню архітектуру. Процесор 680x0 не розуміє двійковий код 80x86, тому він повинен вибрати кожну команду, декодувати її, щоб визначити, для чого вона призначена, а потім виконати еквівалентну підпрограму, написану для 680x0. Так як до того ж у 680x0 немає в точності таких же регістрів, прапорів і внутрішнього арифметико-логічного пристрою, як в 80x86, він повинен імітувати всі ці елементи з використанням своїх регістрів або пам'яті. І він повинен ретельно відтворювати результати кожної команди, що вимагає спеціально написаних підпрограм для 680x0, які гарантують, що стан емульованого регістрів і прапорів після виконання кожної команди буде в точності таким же, як і на реальному 80x86.
Це проста, але дуже повільна робота, так як мікрокод всередині процесора 80x86 виповнюється на значно більш швидкодіючому рівні, ніж адаптовані його зовнішні команди 680x0. За час виконання однієї команди 80x86 на 680x0, реальний 80x86 може виконати десятки команд. Отже, якщо процесор, що виробляє емуляцію, що не настільки швидкий, щоб компенсувати всі втрати при емуляції, то програми, реклама, яка під емуляцією, будуть дуже повільними.
Виходом в таких випадках є використання так званих прикладних середовищ. З огляду на, що основну частину програми, як правило, складають виклики бібліотечних функцій, прикладна середу імітує бібліотечні функції цілком, використовуючи заздалегідь написану бібліотеку функцій аналогічного призначення, а решта команд емулює кожну окремо.
Відповідність стандартам POSIX також є засобом забезпечення сумісності програмних і користувацьких інтерфейсів. У другій половині 80-х урядові агентства США почали розробляти POSIX як стандарти на обладнання, що поставляється при укладанні урядових контрактів в комп'ютерній області. POSIX - це "інтерфейс яку переносять ОС, що базується на UNIX". POSIX - зібрання міжнародних стандартів інтерфейсів ОС в стилі UNIX. Використання стандарту POSIX (IEEE стандарт 1003.1 - 1988) дозволяє створювати програми стилі UNIX, які можуть легко переноситися з однієї системи в іншу.
1 2 3 4 5 6 7 8 9 ... 14