Однією з головних функцій ос є управління всіма пристроями введення-виведення комп’ютера

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

З точки зору призначення пристрої введення-виведення можуть бути умовно розділені на 3 групи:

1) працюють з користувачем (принтери, клавіатура, миша і т.д.);

2) працюють з комп'ютером (носії пам'яті, контролери і т.д.);

3) комунікації (модеми, драйвери і т.д.).

Символьні пристрої здатні приймати або надавати потік символів без блокової структури.

Істотними відмінностями між пристроями в / в є:

1) швидкість передачі даних;

3) складність управління;

4) одиниця передачі даних;

5) надання даних;

6) умови помилок.

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

Розглянемо організацію функцій в / в в залежності від способу здійснення в / в:

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

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

3) прямий доступ до пам'яті здійснюється модулем прямого доступу до пам'яті, який управляє обміном даними між основною пам'яттю і контролером в / в.

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

Кожен драйвер пристрою зазвичай підтримує один тип пристроїв або, максимум, клас близьких пристроїв. Наприклад, драйвер SCSI-дисків зазвичай мо-же підтримувати різні SCSI-диски, що відрізняються розмірами і швидкістю-ми, і можливо навіть буде підтримувати SCSI CD - ROM. З іншого боку, миша і джойстик відрізняються настільки сильно, що зазвичай вимагають використання раз-особистих драйверів. Однак немає ніякого технічного обмеження на управ-ня одним драйвером декількох несхожих пристроїв. Це просто не дуже вдала ідея.

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

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

Мал. Логічне розташування драйверів пристроїв.

Насправді весь обмін інформацією між драйверами і контролерами пристроїв йде по шині

У більшості операційних систем визначено стандартний інтерфейс, кото-рий повинні підтримувати всі блокові драйвери, і другий стандартний інтерфейс, підтримуваний всіма символьними драйверами. Ці інтерфейси включають набори процедур, які можуть викликатися решті операційною системою для звернення до драйверу. До цих процедур відносяться, наприклад, процедури читання блоку (блочного пристрою) або записи символьного рядка (для символів-ного пристрою).

У деяких системах операційна система являє собою єдину дво-ічную програму, яка містить в собі, в відкомпілювався разом з нею вигляді, всі необхідні їй драйвери. Така схема протягом багатьох років була нормою для систем UNIX. так як вони призначалися для роботи в комп'ютерних центрах, а пристрої введення-виведення змінювалися нечасто. При додаванні нового пристрою системний адміністратор просто перекомпілювати ядро ​​з новим драйвером, отримуючи новий двійковий модуль.

З появою персональних комп'ютерів з їх величезною різноманітністю устрій-ств введення-виведення така модель перестала працювати. Далеко не всі користувачі могли самостійно перекомпілювати і зібрати ядро ​​навіть при наявності ис-Ходна текстів чи об'єктних модулів, що, до речі, також не завжди має місце. Замість цього операційні системи, починаючи з MS - DOS. перейшли до моделі динамічної підвантаження драйверів під час виконання системи. Різні системи завантажують драйвери по-різному.

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

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

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

Управління пристроєм на увазі видачу йому серії команд. Саме в драйвері визначається послідовність команд в залежності від того, що повинно бути зроблено. Визначившись з командами, драйвер починає записувати їх в регістри контролера пристрою. Після запису кожної команди в контролер може бути потрібно перевірити, чи прийняв контролер цю команду і готовий прийняти наступну. Така послідовність дій триває до тих пір, поки контролера НЕ будуть дані всі команди. Деякі контролери спо-собнимі приймати зв'язкові списки команд, які перебувають в пам'яті. Вони самі вва-ють і виконують їх без подальшої допомоги операційної системи.

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

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

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

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

Драйверів забороняється звертатися до системних викликів, але їм часто б-кість необхідно взаємодіяти з іншим ядром. Зазвичай вирішуються об-рощення до деяких системних процедур. Наприклад, драйвери звертаються до системних процедур для виділення їм апаратно фіксованих сторінок пам'яті в якості буферів, а також для того, щоб повернути ці сторінки назад ядру. Крім того, драйвери користуються викликами, які керують MMU. таймі розчинами, контролером DMA. контролером переривань і т. п.

1. Обробляти вхідні запити вводу-виводу, що надходять в стандарт
ном форматі.

3. Дозволяти динамічне додавання або видалення пристроїв plug - and - play.

4. Допускати, коли це можливо, управління енергоспоживанням.

5. Допускати реконфігурацію в термінах використання ресурсів.

6. Бути реєнтерабельним для можливості їх використання на МУЛЬТІПРОМ-цессора.