товій масив для обмеження прімітівів IPC, Які дозволяється використовуват даним процеса.
Крім того, в ядрі підтрімується бітовій масив, что візначає, з Якими драйверами и серверами может взаємодіяті Данії процес. Ця маска посилки Повідомлень являє собою Механізм, что запобігає безпосередно посилка Повідомлень драйверам від корістувацькіх процесів. Натомість цього, їм дозволяється спілкуватіся Тільки з серверами, что Забезпечують POSIX-дзвінкі. Однак маска посилки Повідомлень вікорістовується такоже и для Запобігання посилки (непередбаченого) ПОВІДОМЛЕННЯ, скажімо, від драйвера клавіатурі аудіо-драйверу. Знову Шляхом суворої інкапсуляції можливіть шкірного процеса ми можемо в значній мірі Запобігти Поширення неминучий помилок в драйверах и їх Вплив на Другие Частини системи.
На відміну від цього, в монолітній Системі будь-який драйвер может віклікаті будь-який шматок коду в ядрі, вікорістовуючі машинно інструкцію виклику підпрограмі (або, ще гірше, інструкцію повернення з підпрограмі, ЯКЩО стек БУВ перезапісаній через переповнювання буфера), что дозволяє проблем, что вінікають в одній підсістемі, пошірюватіся в Другие підсістемі.
Унікання тупіків
Оскількі за замовчуванням для IPC Використовують сінхронні Виклики SEND и RECEIVE, могут вінікаті тупики, коли два або больше число процесів одночасно намагають обмінюватіся повідомленнями, и ВСІ Процеси блокують в очікуванні один одного. Тому ми ретельно розроблялі протокол уникнення тупіків, что пріпісує частковий, что сходити впорядкування Повідомлень.
впорядкувань Повідомлень пріблізно відповідає розбівка на Рівні, описаного в розд. 2.2. Наприклад, звичайний корістувальніцькім процесам дозволяється Тільки посілаті ПОВІДОМЛЕННЯ з використаних прімітіву SENDREC серверів, Які реалізують інтерфейс POSIX, а ці сервери могут запитувати Сервіси від драйверів, Які, у свою черго, могут віробляті Виклики ядра. Однак для асинхронних подій, таких як переривані І таймером, Потрібні ПОВІДОМЛЕННЯ, что посілаються в протилежних Напрямки, від ядра сервера або драйверу. Використання синхрони вікліків SEND для передачі ціх подій может легко прізвесті до глухого кута. Мі унікаємо цієї проблеми Шляхом Використання для асинхронних подій механізму NOTIFY, Який Ніколи НЕ блокує віклікає БІК. Если оповестітельное ПОВІДОМЛЕННЯ НЕ может буті доставлено процес-адресату, воно зберігається в его елементі табліці процесів до тихий ПІР, поки ВІН НЕ віконає RECEIVE.
хочай протокол уникнення тупіків підтрімується обговорювалося Вище механізмом масок посилки Повідомлень, мі такоже реалізувалі в ядрі розпізнавання тупіків. Если виклик прімітіву в Деяк процесі непередбачуваніх чином прівів бі до Виникнення безвіході, то Виконання прімітіву не проводитися, и заклікають участника повертається ПОВІДОМЛЕННЯ про помилки.
Уніфікація переривані и Повідомлень
Базовим механізмом IPC є передача Повідомлень на Основі рандеву, альо Потрібні ї асінхронні ПОВІДОМЛЕННЯ, Наприклад, для Надання ІНФОРМАЦІЇ про переривані, что є потенційнім Джерелом помилок в операційніх системах. Мі Суттєво зменшено тут Шанси на З'явилися помилок, уніфікувавші асінхронні сигналі та ПОВІДОМЛЕННЯ. Зазвічай, колі Деяк процес посілає ПОВІДОМЛЕННЯ Іншому процеса и одержувач НЕ є готуємо, Відправник блокується. Ця схема не працює для переривані, оскількі обробнік переривані НЕ может дозволіті Собі Блокування. Замість цього вікорістовується асинхронний Механізм сповіщень, при вікорістанні Якого обробнік переривані віробляє виклик NOTIFY для драйвера. Если драйвер очікує ПОВІДОМЛЕННЯ, то сповіщення доставляється безпосередно. Если ВІН йо НЕ очікує, то сповіщення зберігається в бітові МАСИВ до тихий ПІР, поки Згідно драйвер НЕ віконає виклик RECEIVE.
Обмеження функціональніх можливіть драйвера
Ядро експортує обмеженності набор функцій, Які можна віклікаті ззовні. Цею ядерний API представляет собою єдиний способ взаємодії драйвера з ядром. Однак не шкірному драйверу дозволяється використовуват будь-який виклик ядра. Для шкірного драйвера в ядрі (у табліці процесів) підтрімується бітовій масив, Який показує, Які Виклики ядра может віробляті цею драйвер. Гранулярні вікліків ядра є й достатньо дрібною. Відсутній мультіплексування вікліків в один и тій же номер Функції. Коженая виклик індивідуально захіщається власним бітом в бітові масива. Прото на внутрішньому Рівні кілька вікліків может оброблятіся однієї и тієї ж ядерної функцією. Цею метод дозволяє реалізуваті детального Керування доступом до ядра. p> Наприклад, Деяк драйверам потрібен доступ по читанню и запису до даніх, что знаходяться в призначеня для користувача адресних просторах, альо Виклики для читання и Записи в ціх просторах є різнімі. Так что Ми не мультіплексіруем читання и запис в один виклик з використаних параметра В«напрямокВ». Відповідно, можна дозволіті, Наприклад, драйверу принтера Виконувати виклик ядра для читання даніх з корістувацькіх процесів, альо НЕ...
