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

:: Меню ::

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

:: Друзі ::

Карта сайту
 

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

 

 

 

 

 

Завантаження драйверів

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

Термінальний інтерфейс в Unix
На практиці інколи — особливо при використанні багаторівневих драйверів — виявляється можливим перенести окремі функції роботи з пристроями в контекст призначеного для користувача процесу. Одна з відносно вдалих спроб такого перенесення була здійснена в 70-і роки при розробці екранного редактора vi, для ОС Unix (яка тоді ще була єдиним представником того, що потім перетворилося на вельми обширне сімейство ОС).
За задумом розробників цей редактор повинен був працювати з великою кількістю різних відеотерміналів, що використали різні несумісні системи команд для переміщення курсора і редагування тексту в буфері терміналу і настільки ж несумісні схеми кодування спеціальних клавіш (стрілок, функціональних клавіш і ін.). Як і в прикладі з мишами, різні термінали могли підключатися до комп'ютера через різних типів послідовних портів: "струмову петлю", пізніше — Rs232 і ін.
Як в тому, що обговорювався в разд. Багаторівневі драйвери прикладі з мишами, в цьому випадку теж було природно розділити драйвер терміналу на драйвер порту і модуль, що займається генерацією команд і аналізом код розширених клавіш, що приходять від терміналу. Замість розробки окремого модуля, вирішального другу частину завдання, була створена системна база даних для систем команд різних терміналів. Ця база даних є текстовим файлом з ім'ям /etc/termcap (terminal capabilities — можливості терміналу).
Файл /etc/termcap складається з абзаців. Заголовком абзацу є ім'я терміналу, а текст складається з фраз вигляду Name=value, розділених символом ':'. Name є символічним ім'ям тієї або іншої властивості, а value— його значення. Найчастіше це послідовність символів, що формують відповідну команду, або що генеруються терміналом при натисненні відповідної клавіші. Крім того, це може бути, наприклад, ширина екрану терміналу, виміряна в символах.
Для роботи з термінальною базою даних пізніше було створено декілька бібліотек підпрограм — низькорівневу бібліотеку termcap і високорівневий пакет curses.
Для терміналів описаний підхід виявився якщо і не ідеальним, то, в усякому разі, прийнятним. Але, наприклад, для графічних пристроїв він не підійшов — системи команд різних пристроїв виявилися дуже несхожими і такими, що не зводяться до єдиної системи "властивостей".
Першим наближенням до вирішення цієї проблеми стало створення слециалі рованних програм-фільтрів. При використанні фільтрів призначена для користувача програма генерує графічний вивід у вигляді послідовності команд деякої мови. Фільтр приймає ці команди, синтезує на їх основі зображення і виводить його на графічний пристрій. Вся підтримка різних пристроїв виводу покладається на фільтр, призначена для користувача програма повинна лише знати його вхідну мову.
Найвдалішим варіантом мови графічного виводу у наш час считавется Postscript—язик управління інтелектуальними принтерами, розроблений фірмою Adobe. Postscript надає багатий набір графічних примітивів, але основна його перевага полягає в тому, що це повнофункціональна мова програмування з умовними операторами циклами і підпрограмами.
Спочатку ця мова використовувалася лише для управління дорогими моделями лазерних принтерів, але потім з'явилися інтерпретатори цієї мови здатні виводити Postscript на простіші пристрої. Найбільш відомою програмою цього типа є Ghostscript— програма, реалізована в рамках проекту GNU і доступна як freeware. Ghostscript поставляється у вигляді вихідних текстів на мові З, здатна працювати в багатьох операційних системах; практично у всіх ОС сімейства Unix, Os/2, Ms/or DOS і так далі і підтримує практично всі популярні моделі графічних пристроїв, принтерів, плоттерів і іншого устаткування.
Аналогічний підхід використовується у віконній системі X Window. У цій системі весь вивід на термінал здійснюється спеціальною програмою-сервером. На сервер покладається завдання підтримки різних графічних пристроїв. У більшості реалізацій сервер виконується як звичайна призначена для користувача програма, здійснюючи доступ до пристрою за допомогою функцій ioctl "встановити відеорежим" і "відображувати відеопам'ять в адресний простір процесу".

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

 

:: Реклама ::

 

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


 

 

 


Copyright © Kivik, 2017