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

:: Меню ::

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

:: Друзі ::

Карта сайту
 

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

 

 

 

 

 

Укрепление ногтей под шеллак подробности здесь.

Драйвери зовнішніх пристроїв

  Коли я на пошті служив ямщиком .
До мене постукав кудлатий геолог
І дивлячись на карту на білій стіні
він усміхнувся мені.
Г. Самойлов

Драйвер (driver) є спеціалізованим програмним модулем, керівник зовнішнім пристроєм. Слово driver походить від дієслова to drive (вести) і перекладається з англійської мови як візник або шофер: той, КТО веде транспортний засіб. Драйвери забезпечують єдиний інтерфейс для доступу до різних пристроїв, тим самим усуваючи залежність призначених для користувача програм і ядра ОС від особливостей апаратури.
Драйвер не обов'язково повинен управляти яким-небудь фізичним пристроєм. Багато ОС надають також драйвери віртуальних пристроїв або псевдопристроїв — об'єктів, які поводяться аналогічно пристрою введення-виводу, але не відповідають жодному фізичному пристрою.
У вигляді псевдопристроїв реалізуються труби в системах сімейства Unix і поштові скриньки в VMS. Ще одним прикладом корисного псевдопристрою є пристрої /dev/null в Unix і аналогічне йому \DEV\NUL у MS Dos\windows\os/2. У сучасних системах сімейства Unix у вигляді псевдопристроїв, розміщених в псевдофайловій системі /ргос, реалізований доступ до більшості параметрів системи -- адресним просторам активних процесів, статистиці і параметрам налаштування ядра, даним окремих підсистем, наприклад таблиці маршрутизації мережевого протоколу IP.
Прикладні програми, що використовують власні драйвери, не так вже рідкі - прикладами таких програм можуть бути Ghostscript (вільно поширюваний інтерпретатор мови Postscript, здатний виводити програми на цій мові на різні пристрої, що як друкують, так і екранні) або LATEX який також здатний друкувати на найрізноманітніших пристроях. Проте ця глава присвячена переважно драйверам, використовуваним ядром ОС.
Більшість ОС спільного призначення забороняють призначеним для користувача програмам безпосередній доступ до апаратури. Це робиться для підвищення надійності і забезпечення безпеки в розрахованих на багато користувачів системах. У таких системах драйвери є для прикладних програм єдиним способом доступу до зовнішнього світу.
Ще одна важлива функція драйвера- це взаємовиключає доступу до пристрою в середі з витісняючою багатозадачністю. Допускати одночасний неконтрольований доступ до пристрою декількох процесів, що паралельно виконуються, просто не можна, бо для більшості зовнішніх пристроїв навіть прості операції введення-виводу не є атомарними.
Наприклад, в більшості апаратних реалізацій послідовного порту Rs232 передача байта складається з чотирьох кроків: записи значення в регістр даних, записи команди "передавати" в регістр команди, чекання переривання по кінцю передачі і перевірки успішності передачі шляхом прочитування статусного регістра пристрою. Порушення послідовності кроків може приводити до неприємних наслідків — наприклад, перезапис регістра даних після подачі команди, але до завершення передачі, може привести до зупинки передачі або, що ще гірше, передачі спотворених даних і так далі
Не можна також забувати про неприємності більш високого рівня — наприклад, змішуванні виведення різних процесів на друці або даних — на пристрої зовнішньої пам'яті. Тому виявляється необхідно пов'язати з кожним зовнішнім пристроєм якийсь розмежувач доступу в часі. У сучасних ОС ця функція покладається саме на драйвер. Зазвичай одна з ниток драйвера є процесом-монітором, що виконує запити, що асихронно поступають, на доступ до пристрою. У Unix, Os/2 і Windows Nt/2000/xp цей процес називається стратегічною функцією. Детальніше цей механізм обговорюється в разд. Асинхронне уведення-виведення і Асинхронна модель введення-виводу з точки зору додатків.
При визначенні інтерфейсу драйвера розробники ОС повинні знайти правильний баланс між суперечливими вимогами:

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

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

Підсистема введення-виведення Os/2
Як приклад такого консерватизму можна привести підсистему введення-виведення Os/2. Спільний проект фірм IBM і Microsoft, Os/2 1.x розроблялася як операційна система для сімейства персональних комп'ютерів Personal System/2. Молодші моделі сімейства були засновані на 16-розрядному процесорі 80286, тому вся ОС була повністю 16-бітовій.
Пізніше розробники фірми IBM реалізували 32-бітову Os/2 2.0, але для сумісності із старими драйверами їм довелося зберегти 16-бітову підсистему введення-виводу. Всі точки входу драйверів повинні знаходитися в 16-бітових ('Use16') сегментах коди; драйверам передаються лише 16-розрядні ('far') покажчики і так далі
За твердженням фірми IBM, вони розглядали можливість реалізації також і 32-бітових драйверів, але їх виміри не показали значного підвищення продуктивності при переході до 32-бітовій моделі. Пізніше, втім, суперскалярні процесори архітектури х86, оптимізованих виконань Дл^ 32-розрядного коди, все-таки продемонстрували значне зростання продуктивності для такої коди в порівнянні з 16-розрядним, і, починаючи з Os/2 4.0 32-бітовий інтерфейс все-таки надається, але без відмови від підтримки старих, 16-розрядних драйверів.
Завдяки цьому зберігається можливість використовувати драйвери, розроблені ще в кінці 80-х і розраховані на Os/2 1.x. Ця можливість виявляється особливо корисна при роботі із старим устаткуванням.
Навпаки, розробники фірми Microsoft відмовилися від сумісності з 16-бітовими драйверами Os/2 1.x в тій, що створювалася ними 32-бітовій версії Os/2 Os/2 New Technology, що називалася. Фольклор стверджує, що саме це технічне рішення виявилося причиною розриву партнерських відношенні між Microsoft і IBM, в результаті якого Os/2 NT вийшла на ринок під назвою Windows NT 3.1.

Підсистема введення-виведення Windows 9x/me
Сама фірма Microsoft, втім, демонструє майже настільки ж зворушливу прихильність до сумісності із старими драйверами: системи лінії Windows 95/98/me до цих пір використовують вельми своєрідну архітектуру, основний сенс якої — можливість застосовувати, хай і з обмеженнями, драйвери MS DOS.
Windows 9х і Windows 3.x в enhanced-режиме надають витісняючу багатозадачність для VDM (Virtual DOS Machine— Віртуальна машина [для] DOS), проте самі використовують DOS для звернення до дисків і дискет. Ядро однозадачної DOS не уміє віддавати управління іншим процесам під час виконання запитів введення-виводу. В результаті під час звернення до диска всі останні завдання виявляються заблоковані.
В сучасних РС час виконання операцій над жорстким диском вимірюється десятими долями секунди, тому фонові звернення до жорсткого диска майже не приводять до порушень роботи останніх програм. Проте швидкість роботи гнучких дисків залишилася досить низькою, отже, робота з ними у фоновому режимі блокує систему на дуже помітні проміжки часу.
Ефектна і переконлива демонстрація цієї проблеми дуже проста: досить запустити у фоновому режимі форматування дискети або просто команду COPY С:\тмр\*.* А: якщо в каталозі C:\tmp досить багато даних. При цьому працювати з системою буде практично неможливе: під час звернень до дискети навіть мишачий курсор не відстежуватиме рухів миші, втрачатимуться натиснення на клавіші і так далі
Windows 95/98/me використовує декілька методів обходу DOS при зверненнях до диска, тому користувачі цієї системи не завжди стикаються з описаною проблемою. Проте при використанні блокових драйверів реального режиму система як і раніше застосовує DOS як підсистеми введення-виводу, і робота з дискетами у фонових завданнях також порушує роботу завдань першого плану.

Якщо говорити про сумісність, то з багатьох точок зору дуже привабливою представляється ідея універсального драйвера — модуля, який без зміні або з мінімальними змінами може використовуватися Для управління одним і тим же пристроєм в різних ОС.
На жаль — незважаючи навіть на те, що, як ми побачимо далі, у загальних рисах архітектура драйвера в більшості сучасних ОС удівітельн схожа — ідея ця, мабуть, не реалізовується. Навіть для близькоспоріднених ОС — наприклад, систем сімейства Unix — драйвери одного і того ж пристрої не завжди можуть бути легко перенесені з однієї ОС в іншу кажучи вже про можливість використання без модифікацій. Ще дивнішим є той факт, що дві лінії ОС - Windows 95/98/mе і Windows Nt/2000/xp — що поставляються однією і тією ж компанією Microsoft і що реалізовують майже один і той же інтерфейс системних викликів — Win32 — мають зовсім різний інтерфейс драйвера.
Проблема тут в тому, що інтерфейс між драйвером і ядром ОС завжди двосторонній: не лише прикладні програми і ядро викликають функції драйвера, але і, навпаки, драйвер повинен викликати функції ядра. Структура інтерфейсів ядра, доступних драйверу, визначає багато аспектів архітектури ОС в цілому.
У попередніх главах ми вже обговорювали багато з ключових питань: спосіб збірки ядра, стратегію управління пам'яттю, способи обміну даними між ядром і призначеними для користувача процесами, і, нарешті, механізми міжпоточної взаємодії — між нитками самого драйвера (нижче ми побачимо, що переважна більшість драйверів складаються як мінімум з двох ниток), між драйвером і останніми нитками ядра і між драйвером і нитками призначених для користувача процесів.
Виклад вирішень перерахованих проблем складає якщо і не повний опис архітектури ОС, то, в усякому разі, значну його частину. Так, перехід від однозадачної системи або кооперативної багатозадачності до витісняючої багатозадачності може зажадати не лише зміни планувальника, але і радикальної переробки всієї підсистеми введення-виводу, у тому числі і самих драйверів.
Таким чином, до тих пір, поки використовуються ОС різної архітектури, розробка універсального інтерфейсу драйвера, якщо теоретично п можлива, то практично навряд чи осуществіма.

 

:: Реклама ::

 

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


 

 

 


Copyright © Kivik, 2017