ься з вини драйверів прістроїв [7, 25]. Додатковий проблемою.Більше є ті, что Величезне розмір монолітніх ядер Робить їх Дуже Складаний и Важко розуміті. Без загально розуміння ядра даже досвідчений програміст может легко внести помилки за рахунок недостатньої поінформованості про побічні ЕФЕКТ своих Дій.
Системи з мінімальнім ядром
На Іншому полюсі находится мінімальне ядро, что містіть позбав чистий Механізм и ніякої політики. Мінімальна ядро ​​Включає обробнікі переривані, Механізм для запуску та зупинка процесів (Шляхом завантаження регістрів MMU и ЦП), планувальнік и Механізм ПІДТРИМКИ міжпроцесної КОМУНІКАЦІЙ; в ідеальному випадка больше в ядро ​​не заходити Нічого. Підтримка функціональніх можливіть стандартної операційної системи, представленої у монолітному ядрі, переміщається в корістувальніцьке адресності простір, и відповідній код больше не віконується на найбільш прівілейованому Рівні.
Поверх мінімального ядра Можливі Різні організації операційної системи. Одним з варіантів є Виконання всієї операційної системи в одному сервері в режімі користувача, альо в такій архітектурі існують ті ж проблеми, что и в монолітній Системі, и помилки, як и раніше могут прізвесті до аварійного відмові всієї операційної системи, что віконується в режімі користувача. У розд. 6 мі обговоримо деякі роботи в Цій области.
КРАЩИЙ рішенням є Виконання шкірного ненадійного модуля в режімі користувача в окремому процесі, ізольованому від других процесів. Мі до крайності захопіліся цією ідеєю и Повністю роздрібнілі свою систему, як показано на рис. 2. УСІ функціональні компоненти операційної системи, Такі як драйверами прістроїв, файлової системи, сервер мережі та вісокорівневе управління пам'яттю, віконуються як окремі Процеси в режімі користувача у Власний адресного просторі. Цю модель можна візначіті, як мультисерверного операційну систему. p> Зх логічної точки зору Наші корістувальніцькі Процеси можна Розбита на три Рівні, хочай з точки зору ядра ВСІ смороду є Всього позбав процесами. Найніжчій рівень процесів, Які віконуються в режімі користувача, займають драйвером прістроїв, КОЖЕН з якіх керує Деяк прістроєм. Мі реалізувалі драйвер інтерфейсу IDE, Гнучкий и Жорсткий дисків, клавіатурі, дісплеїв, аудіо-пристроїв, принтерів и різніх карт Ethernet. Вище уровня драйверів знаходяться серверні процеси. У їх число входять файловий сервер, сервер процесів, мережевий сервер, інформаційний сервер, сервер реінкарнації та Другие. Над рівнем серверів віконуються звічайні корістувальніцькі Процеси, включаючі Різні інтерпретаторі shell, компіляторі, утіліті та Прикладні програми. Чи не рахуючи невеликого числа віключень, сервери и драйверами є нормальними для користувача процесами.
Щоб унікнуті будь-якої неясності ще раз зауважімо, что Кожний сервер або драйвер віконується у вігляді окрем користувача процеса з власним адресності простором, Повністю відокремленім від адресного простору ядра и других серверів, драйверів и процесів Користувачів. У Нашій архітектурі Процеси НЕ поділяють будь-яке адресності простір и могут спілкуватіся один з одним позбав з використаних механізму IPC, забезпечуваного ядром. Цею аспект є критичним для надійності, оскількі ВІН запобігає Поширення збоїв одного сервера або драйвера на Другие сервери або драйвером подібно до того, як помилка при компіляції програми, что вінікає в одному процесі, що не впліває на ті, что Робить браузер в Іншому процесі.
Під годину роботи в режімі користувача возможности процесів операційної системи обмежені. Тому для ПІДТРИМКИ Виконання необхідніх від них Завдання серверами и драйверами ядро ​​експортує ряд системних вікліків, Які могут віроблятіся авторизовані процесами. Наприклад, драйвер прістроїв больше не мают прівілеїв на безпосереднє Виконання вводу-виводу, альо могут Вимагати від ядра Виконання відповідніх Дій від свого имени. Крім того, сервери та драйверами могут запитувати Сервіси один в одного. Всі Такі IPC проводяться Шляхом обміну невелика повідомленнями фіксованого розміру. Цею обмін повідомленнями реалізується Шляхом звернень до ядра, Яке до Виконання запитуваної Дії перевіряє, Авторизований чг відповіднім чином віклікає процес.
Розглянемо ТИПОВИЙ виклик ядра. Компоненту операційної системи, что віконується в режімі користувача в Деяк процесі, может знадобітіся скопіюваті дані в Інше адресності простір чі з нього, альо Йому Неможливо довіріті можлівість доступу до ФІЗИЧНОЇ пам'яті. Натомість цього Забезпечують Виклики ядра для копіювання з допустимих віртуальніх адресу или в ці адреси сегмента даніх цільового процеса. Цею виклик надає набагато більш слабкі возможности, чем запис в будь-яке слово ФІЗИЧНОЇ пам'яті, альо таки ці возможности й достатньо потужні, и того можлівість такого виклику надається Тільки процесам операційної системи, Яким нужно копіювання блоків даніх з одного адресного простору в Інше. Для звичайна корістувальніцькіх процесів по...
