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

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

While правда do begin

Begin

Таблиця 12.1. Метафайли NTFS

Рис. 12.1. Структура тому NTFS.

MFT (master file table, загальна таблиця файлів) являє собою централізований каталог всіх інших файлів диску, у тому числі і себе самого. MFT поділений на записи фіксованого розміру в 1 Кбайт, і кожен запис відповідає якому-небудь файлу (у загальному значенні цього слова). Перші 16 файлів носять службовий характер і недоступні операційній системі — вони називаються метафайлами, причому найперший метафайл — сам MFT. Ці перші 16 елементів MFT — єдина частина диска, що має строго фіксоване положення. Копія цих же 16 записів зберігається в середині тому для надійності, оскільки вони дуже важливі. Інші частини MFT-файлу можуть розташовуватися як і будь-який інший файл, у довільних місцях диску — відновити його положення можна за допомогою його самого, «зачепивши» за саму основу — за перший елемент MFT.

Згадані перші 16 файлів NTFS (метафайли) носять службовий характер кожний з них відповідає за який-небудь аспект роботи системи. Метафайли знаходяться в кореневому каталозі NTFS-тому. Усі вони починаються із символу імені «$», хоча одержати яку-небудь інформацію про них стандартними засобами складно. У табл.12.1 приведені основні відомі метафайли і їхнє призначення. Таким чином, можна довідатися, наприклад, скільки операційна система витрачає на каталогізацію тому, подивившись на розмір файлу $MFT.

Отже, усі файли тому згадуються в MFT. У цій структурі зберігається вся інформація про файли, за винятком власне даних. Ім'я файлу, розмір положення на диску окремих фрагментів і т.д. – усе це зберігається у відповіднімі записі. Якщо для інформації не вистачає одного запису MFT, то використовується кілька записів, причому не обов'язково йдучих підряд. Файли можуть мати не дуже великий розмір. Тоді застосовується досить вдале рішення: дані файлу зберігаються прямо в MFT, у місці, що залишився від основних даних, у межах одного запису MFT. Файли, що займають сотні байт, звичайно не мають свого «фізичного» втілення в основній файловій області - усі дані такого файлу зберігаються в одному місці, у MFT.

Файл у томі з NTFS ідентифікується так званим файловим посиланням (File Referens), яке представлене як 64-розрядне число. Файлове посилання складається з номера файлу, що відповідає позиції його файлового запису в MFT, і номера послідовності. Останній збільшується всякий раз, коли дана позиція MFT використовується повторно, що дозволяє файловій системі NTFS виконувати внутрішні перевірки цілісності.

Кожен файл у NTFS представлений за допомогою потоків (streams), тобто в нього немає «просто даних» як таких, а є «потоки». Для правильного розуміння досить вказати, що один з потоків і носить звичний нам зміст – дані файлу. Але більшість атрибутів файлу - це теж потоки. У такий спосіб виходить, що базова сутність у файлі тільки одна - номер у MFT, а все інше, включаючи і його потоки, - опційно. Даний підхід може ефективно використовуватися - наприклад, файлу можна «приліпити» ще один потік, записавши в нього будь-які дані. У Windows 2000 у такий спосіб записана інформація про автора і зміст файлу (одна з закладок у властивостях файлу, що переглядаються, наприклад, із провідника). Цікаво, що ці додаткові потоки не видні стандартними засобами роботи зфайлами:
розмір основного потоку, що спостерігається, що містить традиційні дані. Можна, приміром, мати файл нульової довжини, при стиранні якого звільниться 1 Гбайт вільного місця - просто тому, що яка-небудь хитра програма чи технологія «приліпила» до нього додатковий потік (альтернативні дані) такого великого розміру. Але насправді в даний час потоки практично не використовуються, так що побоюватися подібних ситуацій не потрібно, хоча гіпотетично вони можливі. Просто необхідно мати на увазі, що файл у NTFS — це більш глибоке поняття, чим можна собі представити, переглядаючи каталоги диска.

Стандартні ж атрибути для файлів і каталогів у томі NTFS мають фіксовані імена і коди типу, вони перераховані в табл.12.2.

Таблиця 12.2. Атрибути файлів в системі NTFS

Атрибути файлу в записах MFT розташовані в порядку зростання числових значень кодів типу, причому деякі типи атрибутів можуть зустрічатися в записі більш одного разу: наприклад, якщо у файлі є кілька атрибутів даних чи кілька імен. Обов'язковими для кожного файлу в томі NTFS є атрибут стандартної інформації, атрибут імені файлу, атрибут дескриптора захисту й атрибут даних. Інші атрибути можуть зустрічатися при необхідності.

Ім'я файлу в NTFS, на відміну від файлових систем FAT і HPFS, може містити будь-які символи, включаючи повний набір національних алфавітів, тому що дані представлені в Unicode — 16-бітному представленні, що дає 65 535 різних символів. Максимальна довжина імені файлу в NTFS — 255 символів.

Великий внесок в ефективність файлової системи вносить організація каталогу. Каталог у NTFS являє собою спеціальний файл, що зберігає посилання на інші файли і каталоги, створюючи ієрархічну будову даних на диску. Файл каталогу поділений на блоки, кожний з який містить ім'я файлу, базові атрибути і посилання на елемент MFT, що вже надає повну інформацію про елемент каталогу. Головний каталог диска — кореневий — нічим не відрізняється від звичайних каталогів, крім спеціального посилання на нього з початку метафайла MFT.

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

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

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

Можливості файлової системи NTFS по обмеженню доступу до файлів і каталогів.

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

· немає доступу (no access) (None)(немає);

· повний доступ (full control) (А11)(А11) (усі) (усі);

· право читання (read) (RX)(RX) (читання) (читання);

· право додавання (add) (WX)(not specified) (запис/виконання не зазначене);

· право додавання і читання (add&read) (RWX)(RX) (читання/запис/виконання) (читання/виконання);

· право перегляду (list) (RX)(not specified) (читання/виконання)(не зазначене);

· право зміни (change) (R\VXD)(RWXD) (читання/запис/ виконання/видалення) (читання/запис/виконання/видалення).

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

· повний доступ (full control) (All) (її);

· немає доступу (no access) (None) (немає);

· право зміни (change) (RWXD) (читання/запис/виконання/видалення);

· право читанні (read) (RX) (читання/виконання).

Для прав доступу NTFS, як і для прав загальних каталогів, діє принцип поглинання. Виключення складає право «немає доступу», що скасовує доступ всіх інших прав.

При мережному підключенні користувачів права NTFS можуть вступити в конфлікт із правами загальних каталогів. У такій ситуації застосовується право доступу з найбільш жорсткими обмеженнями. У багатьох виникають проблеми з розумінням одержуваних при мережному доступі обмежень. Однак тут можна легко розібратися, якщо пам'ятати, що при доступі по мережі до каталогів і файлів, що розташовуються на томах з NTFS, у нас виходять задіяними два послідовних механізми. Спочатку ми одержуємо доступ до файлів, що був визначений мережними механізмами. Це право «немає доступу» — «no access», право на «читання» — «read», право «зміна» — «change» і «повний доступ» — «full control». Після цього набирають сили обмеження на файли і каталоги, визначені властивостями NTFS. Тобто нам потрібно перебороти послідовно дві перешкоди. Іншими словами, підсумкові права на папки і файли будуть визначатися максимальними обмеженнями, що були задані в кожнім з механізмів.

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

· повний доступ (full control) (Аll);

· читання (read) (R);

· запис (write) (W);

· виконання (execute) (X);

· видалення (delete) (D);

· зміна дозволів (change permissions) (P);

· зміна власника (take ownership) (О).

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

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

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

Три наступних важливі правила допоможуть визначити стан прав доступу при переміщенні, при копіюванні об'єктів NTFS:

· При переміщенні файлів у границях розділу NTFS зберігаються вихідні права доступу.

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

· При переміщенні файлів з розділу NTFS у розділ FAT усі права NTFS губляться.

Основні відмінності FAT і NTFS.

Якщо говорити про накладні витрати на збереження службової інформації, FAT відрізняється від NTFS більшою компактністю і меншою складністю. У більшості томів FAT на збереження таблиці розміщення, що містить інформацію про усі файли тому, витрачається менше 1 Мбайта. Настільки низькі накладні витрати дозволяють форматувати у FAT жорсткі диски малого обсягу і флопі-диски. У NTFS службові дані займають більше місця, ніж у FAT. Так, кожен елемент каталогу займає 2 Кбайт. Однак це має і свої переваги, тому що вміст файлів обсягом 1500 байт і менше може цілком зберігатися в елементі каталогу.

Система NTFS не може використовуватися для форматування флопі-дисків. Не варто користуватися нею для форматування розділів обсягом менше 50-100 Мбайт. Відносно високі накладні витрати приводять до того, що для малих розділів службові дані можуть займати до 25 % обсягу носія. Корпорація Microsoft рекомендує використовувати FAT для розділів об‘ємом 256 Мбайт і менше, a NTFS — для розділів обсягом 400 Мбайт і більше.

Наступний критерій порівняння — розмір файлів. Розділи FAT мають обсяг до 2 Гбайт, VFAT — до 4 Гбайт і FAT32 — до 4 Тбайт. Проте через особливості своєї внутрішньої будови розділи FAT найкраще працюють для розділів обсягом 200 Мбайт і менше. Розділи NTFS можуть досягати 16 Эбайт, однак на даний час через апаратних і інших системних причин, розмір файлів обмежується 2 Тбайт.

Розділи FAT можуть використовуватися практично у всіх операційних системах. За рідкісними винятками, з розділами NTFS можна працювати прямо тільки з Windows NT, хоча і існують для ряду ОС відповідні реалізації систол керування файлами для читання файлів з томів NTFS. Так, наприклад, утиліта (драйвер) NTFSDOS дозволяє читати дані NTFS на комп'ютері, завантаженому в режимі MS-DOS. Однак повноцінних реалізацій для роботи з NTFS поза системою Windows NT поки немає.

Розділи FAT не забезпечують локальної безпеки. З іншого боку, розділи NTFSзабезпечують локальну безпеку як файлів, так і каталогів. Для розділів FAT можуть встановлюватися загальні права, зв'язані з загальним доступом до каталогів у мережі. Однак такий захист не перешкодить користувачу з локальним входом одержати доступ до файлів свого комп'ютера. У відношенні безпеки NTFS виявляється кращим варіантом. Розділи NTFS можуть забороняти чи обмежувати доступ як вилучених, так і локальних користувачів. Отже, до захищених файлів зможуть звернутися лише тікористувачі, яким були надані відповідні права. Нагадаємо, що Windows NT містить спеціальну утиліту CONVERT.EXE, якаперетворить томи FAT в еквівалентні томи NTFS, однак для зворотнього перетворення (з NTFS у FAT) подібних утиліт не існує. Щоб виконати таке зворотнє перетворення, вам доведеться створити розділ FAT, скопіювати в нього файли з розділу NTFS і потім видалити оригінали. Важливо при цьому не забувати і про те, що при копіюванні файлів з NTFS у FAT губляться всі атрибути безпеки NTFS (нагадаємо, що в FAT не передбачені засоби для визначення і наступного збереження цих атрибутів). Останнім часом появилася ще одна дуже важлива обставина, зв'язана з тим, що обсяги дискових механізмів набагато перевищили максимально припустимий розмір, прийнятний для FAT, — 8,4 Гбайт. Ця межа пояснюється максимально можливими значеннями в адресі сектора, для якого, як мивже знаємо, приділяється всього 3 байти. Тому в переважній більшості випадків при роботі в середовищі Windows-систем використовують або FAT32, або NTFS. Остання, безумовно, краще, але вона не підтримується в широко розповсюджених ОС Windows 98 і нині все більш часто зустрічаєма Windows Millennium Edition.

Тема 13. Інтерфейси операційних систем

5. Основні поняття і визначення.

6. Інтерфейс прикладного програмування АРІ.

7. Реалізація функцій АРІ на рівні операційної системи.

8. Реалізація функцій АРІ на рівні системи програмування.

9. Реалізація функцій АРІ за допомогою зовнішніх бібліотек.

10. POSIX інтерфейс.

1. Основні поняття і визначення.

Інтерфейс ОС – це спеціальний інтерфейс системного або прикладного програмування, який призначений для виконання в наступних задачах:

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

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

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

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

В останніх ОС це здійснюється за допомогою графічного інтерфейсу GUI (graphic user interface). Використання інтерфейсу GUI це є частковий випадок виконання задачі вводу/виводу, який фактично не є частиною ядра ОС, але в деяких випадках функції GUI відносяться до основного системного АРІ.

В сучасних ОС існує два підходи до керування задачами в залежності від реалізації АРІ:

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

· в більш складних системах є не одна підпрограма входу, а декілька у відповідністю з кількістю функцій АРІ.

2. Інтерфейс прикладного програмування АРІ.

АРІ (application program interface – інтерфейс прикладного програмування) призначений для використання прикладними програмами системних ресурсів операційної системи, а також функцій які реалізує ОС.

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

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

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

Основні можливості інтерфейсу прикладного програмування доцільно оцінювати по наступних характеристиках:

· ефективність виконання функцій АРІ, що включають в себе швидкість виконання функцій та об’єм обчислювальних ресурсів необхідних для їх виконання;

· функціональна повнота, функції які надаються інтерфейсу;

· залежність прикладної програми від архітектури обчислювальної системи.

3. Реалізація функцій АРІ на рівні операційної системи.

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

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

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

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

4. Реалізація функцій АРІ на рівні системи програмування.

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

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

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

5. Реалізація функцій АРІ за допомогою зовнішніх бібліотек.

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

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

З точки зору ефективності виконання коду цей метод реалізації АРІ має самі низькі результати, тому що зовнішня бібліотека звертається як до функцій ОС, так і до функцій відповідних бібліотек системного програмування. З погляду переміщуваності вихідного коду зовнішні бібліотеки повинні бути доступні в будь – якій з архітектур обчислювальних систем на які орієнтується розроблювана програма. Це можливо, коли зовнішня бібліотека підтримує певний стандарт і системи програмування також підтримують цей стандарт. Однак для більшості зовнішніх бібліотек інших фірм виробників це не так. Наприклад, бібліотека MFS (фірми Microsoft) і бібліотека VSE (фірми Borland) жорстко орієнтовані на архітектуру обчислювальної системи Windiws. Інший приклад, бібліотека SLX (фірми Borland) орієнтована на Windows і Linux.

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

Щодо прикладного програмного забезпечення, то перспектива отримувати переміщуваний код надається таким технологіям, як технологія “клієнт – сервер”, або трьохрівнева архітектура створення програм (прикладна програма – клієнт сервер – функції операційної системи).

Однією з основних характеристик АРІ повинна бути незалежність від системи програмування. Як правило, різні типи АРІ не стандартизовані. Кожному конкретному випадку набір викликів АРІ визначається архітектурою операційної системи та її призначення. В той же час стандартизується деякий обмежений набір функцій з метою полегшення переносу програм з однієї архітектури на іншу. Наприклад, до деякої міри стандарт Win АРІ фірми Microsoft є стандартизований. З точки зору Win АРІ основною задачею є вікно. Таким чином цей стандарт по визначенню орієнтований на роботу в графічному середовищі. Проте окремі функції цього стандарту (наприклад бібліотекиWin АРІ 32, Win АРІ 16, Win АРІ СЕ) не стандартизовані, що накладає певні обмеження при переносі програм з однієї ОС на іншу.

6. POSIX інтерфейс.

POSIX (portable operation system interface for computer environment – платформенно незалежний інтерфейс операційних систем для комп’ютерного середовища).

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

POSIX детально описує систему віртуальної пам’яті, багатозадачність та технологію переміщуваності операційних систем. Тому насправді POSIX є не єдиний стандарт, а набір стандартів POSIX.1 ... POSIX.12. Зокрема, стандарт POSIX.1 описує системний АРІ (мову програмування С), POSIX.4 – задачі реального часу, POSIX.6 – системну безпеку, POSIX.7 – адміністрування системи, POSIX.12 – графічний інтерфейс користувача, тощо. Таким чином програми, які розроблені з урахуванням даних стандартів будуть однаково виконуватись у всіх POSIX сумісних ОС. Однак, в деяких випадках POSIX стандарт має чисто рекомендаційний характер. Частина POSIX стандарту описана строго й детально і невиконання цих вимог не забезпечить переміщуваність програм, інша частина лише поверхнево описує основні вимоги. Деякі програми в документації можуть бути заявлені як POSIX сумісні, але вони такими не є. Ця ситуація виникає у випадках, коли з точки зору забезпечення продуктивності або з погляду впровадження фірмових технологій, які обмежують використання задачі відповідною операційною системою або операційним середовищем, для програмування використовуються інші функції, які безпосередньо працюють з ОС або апаратурою і не підтримують POSIX стандарт.

Тема 14. Архітектура ОС Unix

11. Основні поняття і визначення.

12. Віртуальна машина.

13. Типи та інтерфейс користувачів.

14. Команди та командний інтерпретатор.

15. Процеси та їх виконання.

16. Підсистема вводу/виводу.

17. Структура файлової системи.

18. Засоби захисту файлів і даних.

19. Сигнали і семафори.

20. Програмні канали та черги повідомлень.

21. Розділювана пам’ять та виклики віддалених процедур.

22. Особливості ОС Linux.

1. Основні поняття і визначення.

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

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

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

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

· одні і ті ж механізми працюють у відношенні програмних і апаратних ініціалізованих переривань.

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

Unix системи поставляються з великим набором системних і прикладних програм, включаючи текстові редактори, інтерпретатори командної мови, компілятори з декількох популярних мов програмування (Perl, Assembler, Delphi, C, C++), компоновщики, відладчики, бібліотеки системних і користувацьких програм, засоби сортування і ведення баз даних, багаточисельні адміністративні і обслуговуючі програми. В Unix системах використовується ієрархічна файлова система з повним захистом, робота зі змінними томами (дисками), забезпечується незалежність від пристроїв. Центральною частиною системи Unix є ядро.

2. Віртуальна машина.

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

· процесор;

· пам’ять;

· пристрої;

· файли.

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

· образу пам’яті;

· значень загальних регістрів процесора;

· стану відкритих файлів;

· поточної директорії і іншої інформації.

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

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

· сегмент процедур (починається з нульового адресу у віртуальному адресному просторі процесу);

· сегмент даних (розміщується після сегменту процедур і може зростати в сторону великих адресів);

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

3. Типи та інтерфейс користувачів.

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

Файлова система OC Unix має деревоподібну структуру.

Кожному зареєстрованому користувачу відповідає відповідний каталог (домашній каталог).

Коротко розглянемо інтерфейс користувача. Традиційний спосіб взаємодії користувача з ОС Unix заснований на використанні командних мов. Після входу користувача в систему для нього запускається один із командних інтерпретаторів (в залежності від параметрів які зберігаються в файлі /etc/passwd). Загальна назва будь – якого командного інтерпретатора шел – оболонка. Визваний командний інтерпретатор дає запит дає запит на ввід користувачем командної стрічки, яка може містити просту команду, конвеєр команд, або послідовність команд. Після виконання наступної командної стрічки і видачі на екран терміналу або в файл потрібних результатів, shell знову робить запит на ввід нової командної стрічки.

Командні мови які використовуються в ОС Unix є досить простими, для змоги швидкого навчання новими користувачами. Написання складних програм спирається механізм складних файлів shell – script.

Привілейований користувач.

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

4. Команди та командний інтерпретатор.

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

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

В ОС Unix існує мова програмування оболонки shell, яка складається з наступних частин:

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

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

· команди, які представляються окремими виконуваними файлами.

Простий приклад програмування на мові shell - вивід стрічки на екран.

5. Процеси та їх виконання.

Термін процес в ОС Unix розуміється як програма, яка виконується в власному віртуальному адресному просторі. Для створення нового процесу в ОС Unix використовуються наступні виклики АРІ:

· fork ();

· exec (ім’я програми яка завантажується).

Виклик fork() створює новий адресний простір, стан якого є ідентичним головному процесу. Керування новим процесом передається на команду, яка безпосередньо знаходиться за викликом fork(). Виклик fork() повертає значення “0” в породженому процесі і ціле додаткове число в основному процесі. Це процес ідентифікації.

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

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

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

Кожен процес має одного процеса – породжувача і в свою чергу може породжувати багато інших процесів.

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

Процеси в загальному виконуються в одному з двох станів:

· користувацькому стані – процес виконує тільки користувацьку програму і має доступ до користувацького сегменту даних;

· системному стані – процес виконує підпрограми ядра ОС і має доступ до системного сегменту даних.

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

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

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

6. Підсистема вводу/виводу.

Функції вводу/виводу в ОС Unix задаються за допомогою 5 системних викликів, а саме:

· open;

· close;

· read;

· write;

· seek.

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

· якщо читання (запис) відбувається перший раз з певного файлу, то воно відбувається послідовно з першого байту пам’яті;

· якщо перед поточною операцією читання (запису) була попередня операція читання (запису), то буде зчитано (записано) байти з поточної позиції вказівника файлу;

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

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

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

· будь – яка операція вводу/виводу розглядається як запис в файл або зчитування з файлу. Клавіатура або термінал також інтерпретується як файл;

· доступ до будь – якого файлу (пристрою) здійснюється через його дескриптор (номер). Існує декілька стандартних дескрипторів (файл з дескриптором 1 – стандартний ввід, 2 – стандартний вивід, 3 – стандартне повідомлення про помилки);

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

Тому для правильного функціонування підсистеми вводу/виводу доцільно при розробці власних програм забезпечити правильне використання системних дескрипторів (1 – stdin, 2 – stdout, 3 – stderr).

7. Структура файлової системи.

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

· невикористовуваний (вільний) блок;

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

· і – блок, який складається з опису файлів, які називаються і – вузлами;

· область для зберігання вмісту файлів.

Рис. 14.1. Організація файлів на диску Unix.

Кожен і – вузол містить наступну інформацію:

· ідентифікатор власника файлу;

· ідентифікатор групи власника файлу;

· біти захисту;

· фізичну адресу на диску, де знаходиться вміст цього файлу;

· розмір файлу;

· час створення файлу;

· час останньої модифікації файлу (використання);

· час останньої зміни атрибутів файлу;

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

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

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

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

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

В системах Unix такі зв’язки мають однаковий статус чи права. Файли не належать директоріям, а зв’язки в цих директорія вказують на фізичний файл розміщений на диску.

8. Засоби захисту файлів і даних.

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

· читання;

· запис;

· виконання.

Ці права доступу надаються трьом класам користувачів:

· власнику файлу (користувач, який створив файл);

· групі в яку входить власник;

· всім іншим користувачам.

Кожен файл завжди зв’язаний зі своїм власником, а також групою користувачів в яку входить власник, тобто має певні визначені ідентифікатори UID (user ID) та GID (group ID). Права доступу до файлу може міняти тільки власник, змінити власника файлу може тільки супервізор (адміністратор), змінити групу до якої відноситься файл може адміністратор або власник файлу. Задача, яка виконується в ОС Unix завжди завантажується на виконання від імені певного користувача та від імені певної групи.

Після завантаження зв’язок процесів та користувачів (груп) відбувається за допомогою ідентифікаторів доступу до файлової системи, які мають назву FSUID і FSGID, а також за допомогою ефективних ідентифікаторів EUID і EGID.

При створенні файл він отримує UID (номер користувача), який співпадає з номером FSUID і відповідно отримує ідентифікатор GID та FSGID. При створенні файлу модифікується не сам файл, а каталог, в якому розміщуються нові посилання на новий файл. Знищення файлу полягає в знищенні посилання на нього. Таким чином для створення/знищення файлу в користувача повинно бути право на запис в каталог.

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

9. Сигнали і семафори.

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

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

· значення семафору;

· номер процесу, який останній працював з цим семафором;

· число процесів, які очікують збільшення значення семафору;

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

Для роботи з семафорами є три наступні системні виклики:

· semget, створення і отримання доступу до набору семафорів;

· semop, для маніпуляції (зміни) значень семафорів;

· semctl, для виконання різноманітних керуючих операцій над набором семафорів.

10. Програмні канали та черги повідомлень.

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

Unix розділяє два типи програмних каналів:

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

· неіменованим програмним каналом може користуватися тільки процес, який створив його та процеси, які породжені цим головним процесом.

Для того, щоб створити іменований програмний канал використовується виклик open, щоб створити неіменований програмний канал використовується спеціальний виклик pipe.

Операції зчитування/запису в каналах здійснюється за допомогою системних файлових викликів (read, write, close).

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

· msgget (message get) – створює нову чергу повідомлень і отримання дескриптора нової черги;

· msgsnd (message send) – для відправки повідомлень, тобто для запису повідомлень у відповідну чергу;

· msgrev (message resive) – служить для прийому повідомлення, тобто для вибору повідомлення з певної черги;

· msgctl (message control) – системний виклик для здійснення керуючих функцій.

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

11. Розділювана пам’ять та виклики віддалених процедур.

Для роботи з розділювальною пам’яттю використовуються команди:

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

· shmat, під’єднує сегмент з вказаним дескриптором до віртуальної пам’яті процесу, який звертається до неї;

· shmdt, відключає від віртуальної пам’яті раніше під’єднаний сегмент розділюваної пам’яті;

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

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

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

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

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

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

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

П1хочезайти := правда;

while П2хочезайти do begin { зовнішній цикл очікування }

if вибранийпроцес = другий then begin

П1хочезайти := неправда;

while вибранийпроцес = другий do

П1хочезайти := правда; { внутрішній цикл очікування }

end;

end;

{ початок критичної ділянки П1}

вибранийпроцес := другий;

П1хочезайти := неправда;

... { оператори критичної ділянки П1}

{ кінець критичної ділянки П1}

end;

end;

procedure Процес2

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

1. Then begin
2. Людина і пізнання. Істина і правда
3. Пам’ятники права Київської Русі: звичаї, угоди Русі з Візантією, церковне право, князівське законодавство, «Руська Правда».
4. Правда – це почуття і усвідомлення людиною будь-якого знання (істини чи хиби) як істини.
5. Приклад 1 програми з оператором While
6. Руська Правда — видатна пам’ятка давньоруського права
7. Салічна правда”, “Капітулярій про вілли” – твори раннього середньовіччя.
8. СЦЕНІЧНА ПРАВДА
9. Цикл WHILE.

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