Архітектура операційної системи UNIX

1. 10.1.1 Конфігурація системи
2. 10.1.2 Системні функції і взаємодія з драйверами
3. 10.1.3 Програми обробки переривань

Наша взаимовыгодная связь https://banwar.org/

В системі UNIX є два типи пристроїв - пристрої введення / виведення блоками і пристрої неструктурованого або посимвольного введення-виведення. Як вже говорилося в розділі 2 , Пристрої введення-виведення блоками, такі як диски та стрічки, для іншої частини системи виглядають як пристрої, що запам'ятовують з довільною вибіркою; до пристроїв посимвольного введення-виведення відносяться всі інші пристрої, в тому числі термінали та мережеве обладнання. Пристрої введення-виведення блоками можуть мати інтерфейс і з пристроями посимвольного введення-виведення.

Користувач взаємодіє з пристроями через посередництво файлової системи (див. малюнок 2.1 ). Кожен пристрій має ім'я, схоже на ім'я файлу, і користувач звертається до нього як до файлу. Спеціальний файл пристрою має індекс і займає місце в ієрархії каталогів файлової системи. Файл пристрою відрізняється від інших файлів типом файлу, що зберігається в його індексі, або "блоковий", або "символьний спеціальний", в залежності від пристрою, який цей файл являє. Якщо пристрій має як блоковий, так і символьний інтерфейс, він уявляється два файли: спеціальний файл пристрою введення-виведення блоками і спеціальний файл пристрою посимвольного введення-виведення. Системні функції для звичайних файлів, такі як open, close, read і write, мають те ж значення і для пристроїв, в чому ми переконаємося пізніше. Системна функція ioctl надає процесам можливість управляти пристроями посимвольного введення-виведення, але не може бути застосована відносно до файлів звичайного типу ( * ). Проте, драйверампристроїв немає необхідності підтримувати повний набір системних функцій. Наприклад, вищезгаданий драйвер трасування дає процесам можливість читати записи, створені іншими драйверами, але не дозволяє створювати їх.

10.1.1 Конфігурація системи

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

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

Інтерфейс "ядро - драйвер" описується в таблиці ключів пристроїв введення-виведення блоками і в таблиці ключів пристроїв посимвольного введення-виведення ( малюнок 10.1 ). Кожен тип пристрою має в таблиці точки входу, які при виконанні системних функцій адресують ядро ​​до відповідного драйверу. Функції open і close, що викликаються файлом пристрою, "пропускаються" через таблиці ключів пристроїв відповідно до типу файлу. Функції mount і umount так само викликають виконання процедур відкриття і закриття пристроїв, але для пристроїв введення-виведення блоками. Функції read і write, що викликаються пристроями введення-виведення блоками і файлами в змонтованих файлових системах, запускають алгоритми роботи з буферним кешем, які ініціюють реалізацію стратегічної процедури роботи з пристроями. Деякі з драйверів запускають цю процедуру зсередини з процедур читання і запису. Більш докладно взаємодію з кожним драйвером розглядається в наступному розділі.

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

Адміністратори встановлюють спеціальні файли пристроїв командою mknod, в якій вказується тип файлу (блоковий або символьний), старший і молодший номера пристрою. Команда mknod запускає виконання системної функції з тим же ім'ям, що створює файл пристрою. Наприклад, в командному рядку

mknod / dev / tty13 c 2 13

"/ Dev / tty13" - ім'я файлу пристрою, "c" вказує, що тип файлу - "символьний спеціальний" ( "b", відповідно, блоковий), "2" - старший номер пристрою, "13" - молодший номер пристрою. Старший номер пристрою показує його тип, якому відповідає точка входу в таблиці ключів пристроїв, молодший номер пристрою - це порядковий номер одиниці пристрої даного типу. Якщо процес відкриває спеціальний блоковий файл з ім'ям "/ dev / dsk1" і кодом 0, ядро ​​запускає програму gdopen в точці 0 таблиці ключів пристроїв блокового введення-виведення ( малюнок 10.2 ); якщо процес читає спеціальний символьний файл з ім'ям "/ dev / mem" і кодом 3, ядро ​​запускає програму mmread в точці 3 таблиці ключів пристроїв посимвольного введення-виведення. Програма nulldev - це "порожня" програма, яка використовується в тих випадках, коли відсутня необхідність в конкретної функції драйвера. З одним старшим номером устрою може бути пов'язано безліч периферійних пристроїв; молодший номер пристрою дозволяє відрізнити їх одне від іншого. Не потрібно створювати спеціальні файли пристроїв при кожному завантаженні системи; їх тільки треба коригувати, якщо змінилася конфігурація системи, наприклад, якщо до встановленої конфігурації були додані пристрої.

Малюнок 10.1. Точки входу для драйверів

10.1.2 Системні функції і взаємодія з драйверами

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

Малюнок 10.2. Приклад заповнення таблиць ключів пристроїв введення-виведення блоками і символами

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

> Алгоритм open / * для драйверів пристроїв * / вхідна інформація: ім'я шляху пошуку режим відкриття вихідна інформація: дескриптор файлу {перетворити ім'я шляху пошуку в індекс, збільшити значен ня лічильника посилань в індексі; виділити в таблиці файлів місце для призначеного для користувача дескриптора файлу, як при відкритті звичайного файлу; вибрати з індексу старший і молодший номера пристрою; зберегти контекст (алгоритм setjmp) в разі передачі управління від драйвера; якщо (пристрій блочного типу) {використовувати старший номер пристрою в якості ука- зателя в таблиці ключів пристроїв введення-виведення бло- ками; викликати процедуру відкриття драйвера з даного індек- су: передати молодший номер пристрою, режими відкриття; } В іншому випадку {використовувати старший номер пристрою в якості ука- зателя в таблиці ключів пристроїв посимвольного вво- да-виводу; викликати процедуру відкриття драйвера з даного індек- су: передати молодший номер пристрою, режими відкриття; } Якщо (відкриття в драйвері не виповнилося) привести таблицю файлів до первісного вигляду, зменшити значення лічильника в індексі; }

Малюнок 10.3. Алгоритм відкриття пристрою

10.1.2.1 Open

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

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

Якщо під час відкриття пристрою процесу довелося зупинитися з якої-небудь із зовнішніх причин, може так статися, що подія, яка мала б викликати відновлення виконання процесу, так ніколи і не відбудеться. Наприклад, якщо на даному терміналі ще не зареєструвався жоден з користувачів, процес getty, "відкрив" термінал ( розділ 7.9 ), Призупиняється до тих пір, поки користувач не буде зроблена спроба реєстрації, при цьому може пройти досить великий проміжок часу. Ядро має мати можливість відновити виконання процесу і скасувати виклик функції open після отримання сигналу: йому слід скинути індекс, скасувати точку входу в таблиці файлів і призначений для користувача дескриптор файлу, які були виділені перед входом в драйвер, оскільки відкриття не відбулося. Ядро зберігає контекст процесу, використовуючи алгоритм setjmp ( розділ 6.4.4 ), Перш ніж запустити процедуру open; якщо процес поновлюється за сигналом, ядро ​​відновлює контекст процесу в тому стані, яке він мав перед зверненням до драйверу, використовуючи алгоритм longjmp ( розділ 6.4.4 ), І повертає системі все виділені процедурі open структури даних. Точно так само і драйвер може вловити сигнал і очистити доступні йому структури даних, якщо це необхідно. Ядро також переустановлює структури даних файлової системи, коли драйвер стикається з винятковими ситуаціями, такими, як спроба користувача звернутися до пристрою, відсутньому в даній конфігурації. У подібних випадках функція open не виконується.

Процеси можуть вказувати значення різних параметрів, що характеризують особливості виконання процедури відкриття. З них найбільш часто використовується "no delay" (без затримки), що означає, що процес не буде припинений під час виконання процедури open, якщо пристрій не готовий. Системна функція open повертає управління негайно і призначений для користувача процес не дізнається, чи відбулося апаратне з'єднання чи ні. Відкриття пристрою з параметром "no delay", крім усього іншого, торкнеться семантику виклику функції read, що ми побачимо далі ( розділ 10.3.4 ).

Якщо пристрій відкривається багато разів, ядро ​​обробляє призначені для користувача дескриптори файлів, індекс і записи в таблиці файлів так, як це описано в розділі 5 , Запускаючи яка визначається типом пристрою процедуру open при кожному виклику системної функції open. Таким чином, драйвер пристрою може підрахувати, скільки разів пристрій було "відкрито", і перервати виконання функції open, якщо кількість відкриттів прийняло неприпустиме значення. Наприклад, має сенс дозволити процесам багаторазово "відкривати" термінал на запис для того, щоб користувачі могли обмінюватися повідомленнями. Але при цьому не слід допускати багаторазового "відкриття" друкувального пристрою для одночасного запису, так як процеси можуть затерти один одному інформацію. Ці відмінності мають сенс скоріше на практиці, ніж на стадії розробки: дозвіл одночасного запису на термінали сприяє встановленню взаємодії між користувачами; заборона одночасного запису на принтери служить підвищенню читабельність машинограм ( ** ).

> Алгоритм close / * для пристроїв * / вхідна інформація: дескриптор файлу вихідна інформація: відсутній {виконати алгоритм стандартного закриття (глава 5ххх); якщо (значення лічильника посилань в таблиці файлів не 0) перейти на finish; якщо (існує ще один відкритий файл, старший і млад- ший номера якого збігаються з номерами, що закривається пристрої) перейти на finish; / * Не останнє закриття * / якщо (пристрій символьного типу) {використовувати старший номер в якості покажчика в таблиці ключів пристрої посимвольного введення-виводи- так; викликати процедуру закриття, яка визначається типом драй- віра і передати їй як параметр молодший но заходів пристрої; } Якщо (пристрій блочного типу) {якщо (пристрій монтувати) перейти на finish; переписати блоки пристрою з буферного кешу на уст- ройство; використовувати старший номер в якості покажчика в таблиці ключів пристрої введення-виведення блоками; викликати процедуру закриття, яка визначається типом драй- віра і передати їй як параметр молодший но заходів пристрої; зробити недійсними блоки пристрою, оставшіе- ся в буферному кеші; } Finish: звільнити індекс; }

Малюнок 10.4. Алгоритм закриття пристрою

10.1.2.2 Closе

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

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

1. Проглядається таблиця файлів для того, щоб переконатися в тому, що жодному з процесів не потрібно, щоб пристрій було відкрито. Щоб встановити, що виклик функції close для пристрою є останнім, недостатньо покластися на значення лічильника посилань в таблиці файлів, оскільки кілька процесів можуть звертатися до одного й того ж пристрою, використовуючи різні точки входу в таблиці файлів. Так само недос таточно покластися на значення лічильника в таблиці індексів, оскільки одному і тому ж пристрою можуть відповідати кілька файлів пристрою. Наприклад, команда ls -l покаже, що одному і тому ж пристрою символьного типу ( "c" на початку рядка) відповідають два файли пристрою, старший і молодший номера у яких (9 і 1) збігаються. Значення лічильника зв'язків для кожного файлу, що дорівнює 1, говорить про те, що є два індексу. crw - w - w- 1 root vis 9, 1 Aug 6 1984 / dev / tty01

crw - w - w- 1 root unix 9, 1 May 3 15:02 / dev / tty01 Якщо процеси відкривають обидва файли незалежно один від іншого, вони звернуться до різних індексах одного і того ж пристрою.

1. Якщо пристрій символьного типу, ядро ​​запускає процедуру закриття пристрою і повертає управління в режим завдання. Якщо пристрій блочного типу, ядро ​​переглядає таблицю результатів монтування і перевіряє, чи не розташовується чи на пристрої змонтована файлова система. Якщо така система є, ядро ​​не зможе запустити процедуру закриття пристрою, оскільки не був зроблений останній виклик функції close для пристрою. Навіть якщо на пристрої немає змонтованої файлової системи, в буферному кеші ще можуть перебувати блоки з даними, що залишилися від змонтованої раніше файлової системи і не переписані на пристрій, оскільки мали позначку "відкладений запис". Тому ядро ​​переглядає буферний кеш в пошуках таких блоків і переписує їх на пристрій перед запуском процедури закриття пристрою. Після закриття пристрою ядро ​​знову переглядає буферний кеш і робить недійсними всі буфери, які містять блоки для щойно закритого пристрою, в той же врємя дозволяючи буферам з актуальною інформацією залишитися в кеші.
2. Ядро звільняє індекс файлу пристрою. Коротше кажучи, процедура закриття пристрою розриває зв'язок з пристроєм і ініціалізує заново інформаційні структури драйвера і апаратну

частина пристрою з тим, щоб ядро ​​могло б пізніше відкрити пристрій знову.

10.1.2.3 Read і Writе

Алгоритми читання і запису ядром на пристрої схожі на аналогічні алгоритми для файлів звичайного типу. Якщо процес виробляє читання або запис на пристрої посимвольного введення-виведення, ядро ​​запускає процедури read або write, що визначаються типом драйвера. Незважаючи на часто зустрічаються ситуації, коли ядро ​​здійснює передачу даних безпосередньо між адресним простором завдання і пристроєм, драйвери пристроїв можуть буферизувати інформацію всередині себе. Наприклад, термінальні драйвери для буферизації даних використовують символьні списки ( розділ 10.3.1 ). У таких випадках драйвер пристрою виділяє "буфер", копіює дані з простору завдання при виконанні процедури write і виводить їх з "буфера" на пристрій. Процедура запису, керована драйвером, регулює обсяг виведеної інформації (т.зв. управління потоком даних): якщо процеси генерують інформацію швидше, ніж пристрій виводить її, процедура запису призупиняє виконання процесів до тих пір, поки пристрій не буде готове прийняти наступну порцію даних. При читанні драйвер пристрою поміщає дані, отримані від пристрою, в буфер і копіює їх з буфера в нестандартні адреси, зазначені у виклику системної функції.

Малюнок 10.5. Відображення в пам'яті вводу-виводу з використанням контролера VAX DZ11

Конкретний метод взаємодії драйвера з пристроєм визначається особливостями апаратури. Деякі з машин забезпечують відображення введення-виведення в пам'яті, що має на увазі, що конкретні адреси в адресному просторі ядра не є номерами осередків у фізичній пам'яті, а спеціальними регістрами, контролюючими відповідні пристрої. Записуючи в зазначені регістри керуючі параметри у відповідності зі специфікаціями апаратних засобів, драйвер здійснює управління пристроєм. Наприклад, контролер введення-виведення для машини VAX-11 містить спеціальні регістри для запису інформації про стан пристрою (регістри контролю і стану) і для передачі даних (буферні регістри), які формуються за спеціальними адресами у фізичній пам'яті. Зокрема, термінальний контролер VAX DZ11 управляє 8 асинхронними лініями термінальної зв'язку (див. [Levy 80], де більш детально пояснюється архітектура машин VAX). Нехай регістр контролю і стану (CSR) для конкретного терміналу DZ11 має адресу 160120, передає буферний регістр (TDB) - адреса 120126, хто ж приймає буферний регістр (RDB) - адреса 160122 ( малюнок 10.5 ). Для того, щоб передати символ на термінал "/ dev / tty09", драйвер терміналу записує одиницю (1 = 9 по модулю 8) в зазначений двійковий розряд регістра контролю і стану і потім записує символ в передавальний буферний регістр. Запис в передавальний буферний регістр є передачею даних. Контролер DZ11 виставляє біт "виконано" в регістрі контролю і стану, коли готовий прийняти наступну порцію даних. Додатково драйвер може виставити біт "можливо переривання передачі" в регістрі контролю і стану, що змушує контролер DZ11 переривати роботу системи, коли він готовий прийняти наступну порцію даних. Читання даних з DZ11 проводиться аналогічно.

На інших машинах є програмований введення-виведення, що має на увазі, що в машині є інструкції з управління пристроями. Драйвери керують пристроями, виконуючи відповідні інструкції. Наприклад, в машині IBM 370 є інструкція "Start I / O" (Почати введення-виведення), яка ініціює операцію введення-виведення, пов'язану із влаштуванням. Спосіб зв'язку драйвера з периферійними пристроями непомітний для користувача.

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

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

10.1.2.4 Стратегічний інтерфейс

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

Наприклад, після монтування файлової системи ядро ​​ідентифікує кожен файл в файловій системі за номером пристрою і номеру індексу. У номері пристрої закодовані його старший і молодший номера. Коли ядро ​​звертається до блоку, який належить файлу, воно копіює номер пристрою і номер блоку в заголовок буфера, як уже говорилося раніше в розділі 3 . Звернення до диска, що використовують алгоритми роботи з буферним кешем (наприклад, bread або bwrite), ініціюють виконання стратегічної процедури, яка визначається старшим номером пристрою. Стратегічна процедура використовує значення полів молодшого номера і номера блоку з заголовка буфера для ідентифікації місця розташування даних на пристрої, а адреса буфера - для ідентифікації місця призначення переданих даних. Точно так же, коли процес звертається до пристрою введення-виведення блоками безпосередньо (наприклад, відкриваючи пристрій і читаючи або записуючи на нього), він використовує алгоритми роботи з буферним кешем, і інтерфейс при цьому функціонує вищеописаним чином.

10.1.2.5 Ioctl

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

Синтаксис командного рядка, що містить виклик системної функції:

ioctl (fd, command, arg);

де fd - дескриптор файлу, що повертається попередньо викликаної функцією open, command - дія (команда), яке необхідно виконати драйверу, arg - параметр команди (може бути покажчиком на структуру). Команди специфічні для різних драйверів; отже, кожен драйвер інтерпретує команди у відповідності зі своїми внутрішніми специфікаціями, від команди, в свою чергу, залежить формат структури даних, описуваної переданим параметром. Драйвери можуть зчитувати структуру даних arg з простору завдання відповідно до наперед визначеним форматом або записувати установки пристрою в простір завдання за адресою вказаною структури. Наприклад, наявність інтерфейсу, що надається функцією ioctl, дає можливість користувачам встановлювати для терміналу швидкість передачі інформації в бодах, перемотувати магнітну стрічку, і, нарешті, виконувати мережеві операції, задаючи номери віртуальних каналів і мережеві адреси.

10.1.2.6 Інші функції, що мають відношення до файлової системи

Такі функції роботи з файловою системою, як stat і chmod, виконуються однаково, як для звичайних файлів, так і для пристроїв; вони маніпулюють з індексом, не звертаючись до драйверу. Навіть системна функція lseek працює для пристроїв. Наприклад, якщо процес підводить головку на стрічкопротяжного пристрої до вказаної адреси зміщення в байтах за допомогою функції lseek, ядро ​​коригує зміщення в таблиці файлів але не виконує ніяких дій, специфічних для даного типу драйвера. Коли пізніше процес виконує читання (read) або запис (write), ядро ​​пересилає адреса зміщення з таблиці файлів в адресний простір завдання, подібно до того, як це має місце при роботі з файлами звичайного типу, і пристрій фізично переміщує головку до відповідного зміщення, вказаною в просторі завдання. Цей випадок ілюструється на прикладі в розділі 10.3 .

Малюнок 10.6. Переривання від пристроїв

10.1.3 Програми обробки переривань

Як вже говорилося вище ( розділ 6.4.1 ), Виникнення переривання спонукає ядро ​​запускати програму обробки переривань, в основі алгоритму якої лежить співвідношення між пристроєм, що викликав переривання, і зміщенням в таблиці векторів переривань. Ядро запускає програму обробки переривань для даного типу пристрою, передаючи їй номер пристрою або інші параметри для того, щоб ідентифікувати одиницю пристрої, що викликала переривання. Наприклад, в таблиці векторів переривань на малюнку 10.6 показані дві точки входу для обробки переривань від терміналів ( "ttyintr"), кожна з яких використовується для обробки переривань, що надійшли від 8 терміналів. Якщо пристрій tty09 перервало роботу системи, система викликає програму обробки переривання, асоційовану з місцем апаратного підключення пристрою. Оскільки з одним записом в таблиці векторів переривань може бути пов'язано безліч фізичних пристроїв, драйвер повинен вміти вибирати користувача, що викликало переривання. На малюнку записи в таблиці векторів переривань, відповідні переривань від терміналів, мають позначки 0 і 1, щоб система розрізняла їх між собою при виклику програми обробки переривань, використовуючи наприклад цей номер як переданого програмі параметра. Програма обробки переривань використовує цей номер і іншу інформацію, передану механізмом переривання, для того, щоб упевнитися, що саме пристрій tty09, а не tty12, перервало роботу системи. Цей приклад в спрощеному вигляді показує те, що має місце в реальних системах, де насправді існує кілька рівнів контролерів і відповідних програм обробки переривань, але він ілюструє загальні принципи.

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

(*) І навпаки, системна функція fcntl забезпечує контроль над діями, виробленими на рівні дескриптора файлу, але не на рівні пристрою. В інших реалізаціях функція ioctl застосовна для файлів усіх типів.

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