Принципи проектування й компоненти системи Linux 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Принципи проектування й компоненти системи Linux



Linux - багатокористувацька й багатозадачна ОС із повним набором UNIX-сумісних інструментів.

Її файлова система відповідає традиційній семантиці UNIX. Вона повністю реалізує стандартну мережну модель UNIX.

Основні цілі проектування Linux - швидкість, ефективність і стандартизація.

ОС Linux розроблена як система, сумісна зі стандартами POSIX, принаймні два дистрибутиви Linux були офіційно сертифіковані як сумісні з POSIX. Програмний інтерфейс Linux відповідає семантиці діалекту SVR4 UNIX (розробленого фірмою AT&T), але не діалекту BSD UNIX (розробленого університетом Беркли).

Компоненты системи Linux зображені на рис. 25.2.

Рис. 25.2. Компоненти системи Linux.

Як більшість реалізацій UNIX, Linux складається із трьох основних груп коду - ядро, системні бібліотеки й системні утиліти; найбільш важлива розходження між ядром і всіма іншими компонентами.

Ядро відповідає за підтримку основних концепцій (абстракцій) ОС.

Код ядра виконується в привілейованому режимі, і йому повністю доступні всі апаратні ресурси комп'ютера.

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

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

Системні утиліти виконують індивідуальні специфічні завдання.

Модулі ядра, що завантажують, Linux

Одним з найважливіших нововведень у ядрі Linux є завантажують модули, що, ядра (loadable kernel modules, LKM), що з'явилися у версії 1.2. Вони забезпечують ядру гнучкість і функціональність.

Частини (секції) коду ядра можуть компілюватися, завантажуватися й вивантажуватися, незалежно від іншої частини ядра.

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

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

Модулі ядра дозволяють инсталлировать Linux у вигляді стандартного, мінімального ядра, без використання яких-небудь убудованих пристроїв.

Три компоненти модуля Linux підтримують:

· Керування модулем

· Реєстрацію драйвера

· Дозвіл конфліктів.

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

Керування модулем розбито на дві частини:

· Керування частинами коду модуля в пам'яті ядра

· Керування символами, на які модуль дозволяє посилатися.

Компонента module requestor управляє завантаженням запитаних, але ще не завантажених модулів. Вона також регулярно опитує ядро, щоб переконатися, що модуль дотепер використається, і вивантажує модуль, якщо він довгий час активно не використався.

Схема вихідного коду модуля ядра, що завантажує, Linux зображена рис. 25.3.

.

Рис. 25.3. Схема вихідного коду модуля ядра, що завантажує, Linux.

Компонента реєстрація драйверів надає модулю можливість повідомити ядру, що новий драйвер доступний.

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

Таблиці реєстрації включають наступні елементи:

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

· Файлові системи

· Мережні протоколи

· Двійкові формати.

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

Цілі модуля дозволу конфліктів:

· Запобігти конфліктам, пов'язані з використанням апаратур

· Запобігти автопроверки (autoprobes) від перетинання із уже існуючими драйверами пристроїв

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

Керування процесами в Linux

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

· Системний виклик fork створює новий процес

· Нова програма запускається за допомогою систебагато виклику exec.

В UNIX процес містить всю інформацію, що ОС повинна підтримувати для реалізації концепції окремого виконання окремої програми.

У системі Linux властивості процесу діляться на три групи: ідентифікація процесу, його оточення й контекст.

Ідентифікатор процесу (PID) - унікальний ідентифікатор процесу (число); використається для вказівки процесів в операційній системі, коли додаток виконує системний виклик signal, modify або wait для іншого процесу.

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

Ідентифікація особистості (Personality). Хоча це й нетрадиційно для систем типу UNIX, в Linux кожен процес має унікальний ідентифікатор особистості, за допомогою якого можлива деяка модифікація семантики ряду системних викликів. Він використовується головним чином у бібліотеках емуляції, для запиту про сумісність системних викликів з тим або іншим специфічним діалектом UNIX.

Оточення процесу успадковується від процесу-батька. Складається із двох векторів, що завершуються нулями:

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

· Вектор оточення – список пара "NAME=VALUE", які зв'язують змінні оточення із заданими іменами і їх довільні текстові значення.

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

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

Контекст процесу – це що постійно змінюється стан виконує программы, що, у будь-який момент часу.

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

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

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

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

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

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

Процеси й потоки. Linux використає те саме внутрішнє подання для процесів і потоків. Потік в Linux – це новий процес, що використає загальний адресний простір із процесом-батьком.

Различие проявляється тільки у випадку, коли новий потік створюється системним викликом clone:

· класичний системний виклик fork створює новий процес зі своїм повністю новим контекстом;

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

Використання систебагато виклику clone дає процесам можливість явного контролю над тим, які ресурси спільно використаються потоками.

Планування завдань ядра й синхронізація в ядрі

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

Запит на виконання в режимі ядра може виникнути у двох випадках:

· Програма, що виконується, може запросити сервіс ОС, як явно за допомогою системного виклику, так і неявно, наприклад, при відмові сторінки

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

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

Linux використає два методи для захисту критичних секцій:

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

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

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

Служби обробки переривань діляться на верхню половину (top half) і нижню половину (bottom half):

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

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

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

На рис. 25.4 зображено рівні захисту переривань.

Рис. 25.4. Рівні захисту переривань.

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

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

Linux використає два алгоритми планування процесів:

· Алгоритм поділу часу для рівноправного планування з перериваннями між різними процесами

· Алгоритм реального часу для випадку, коли абсолютні пріоритети більше важливі, чим рівноправність.

Клас планування процесу визначає, який саме алгоритм застосувати.

Для процесів з поділом часу Linux використає алгоритм на основі довіри (credits) із пріоритетами (priority). Правило credits:= credits / 2 + priority ураховує як історію процесу, так і його пріоритет. По такій системі автоматично визначаються пріоритети інтерактивних процесів або виконуючий ввід-вивід.

Linux реалізує класи планування: FIFO й round-robin; в обох випадках кожен процес має пріоритет, а не тільки певний клас планування.

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

FIFO - процеси виконуються до їхнього завершення або блокування.

round-robin - процес буде перерваний через якийсь час і поміщений у кінець черги планування, так що RR-процеси однакового пріоритету автоматично розділяють час між собою.

Версія Linux 2.0 була першим ядром Linux, що підтримує З; різні процеси або потоки можуть виконуватися паралельно на декількох процесорах.

Для дотримання вимог ядра про виконання без переривань, SMP накладає наступне обмеження: не більш ніж один процес у кожен момент може виконувати код у режимі ядра.

 


 

 



Поделиться:


Последнее изменение этой страницы: 2016-07-11; просмотров: 217; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 18.220.225.21 (0.033 с.)