дібні Виклики Заборонені.
После Приведення цього Опису структурованих операційної системи ми можемо тепер поясніті, Яким чином корістувальніцькі Процеси отримуються Сервіси операційної системи, візначені в стандарті POSIX. Корістувальніцькій процес, Який бажає віконаті, Наприклад, виклик READ, формує ПОВІДОМЛЕННЯ, что містіть номер системного виклику і (покажчики на) параметри, и звертається до ядра Із Запитів посилки цього невеликого запітної ПОВІДОМЛЕННЯ файлового сервера, что є іншім призначеня для користувача процесом. Ядро Забезпечує Блокування віклікає процеса до тихий ПІР, поки его запит не якщо опрацьовано файловим сервером. За замовчуванням УСІ комунікації между процесами забороняються з міркувань безпеки, альо цею запит досягає мети, оскількі комунікації з файловим сервером явно вірішуються звичайна корістувальніцькім процесам.
Если запітувані містяться в буферному кеші файлового сервера, то ВІН віробляє виклик ядра Із Запитів копіювання ціх даних до буфер користувача. Если у файлового сервера відсутні необхідні дані, то ВІН посілає ПОВІДОМЛЕННЯ дисковому драйверу Із Запитів потрібного блоку. Тоді дисковий драйвер відає команду диска на читання цього блоку прямо за адресою всередіні буферного кешу файлового сервера. Колі передача даніх з диска завершується, дисковий драйвер посілає файлового серверу ПОВІДОМЛЕННЯ у відповідь, что містіть стан запиту (Успіх або причина невдачі). После цього файловий сервер Робить виклик ядра Із Запитів копіювання блоку в корістувальніцьке адресності простір.
Ця схема проста и Елегантна, вона дозволяє відокреміті сервери и драйверами від ядра и дозволяє замінюваті їх пробачимо чином, что спріяє модульності системи. Хочай тут нужно до чотірьох Повідомлень, смороду передаються Дуже Швидко (в межах 500 наносекунд на ПОВІДОМЛЕННЯ в залежності від ЦП). Если и Відправник, и одержувач Готові до комунікації, ті ядро ​​копіює ПОВІДОМЛЕННЯ прямо з буфера Відправник у буфер одержувача без его переміщення в адресний простір ядра. Крім того, число копіювань даніх є точно таким же, як в монолітній Системі: диск поміщає дані прямо в буферний кеш файлового сервера, та є Одне копіювання з цього кеша в Адресні простір корістувацького процеса.
Принципи розробки
Перш чем перейти до докладного РОЗГЛЯДУ властівостей надійності Нашої системи, коротко обговоримо принципи розробки, Якими ми керували у прагненні до надійності:
1. Простота. p> 2. Модульність. p> 3. Найменша Авторизація. p> 4. Відмовостійкість. p> По-перше, ми зберігаємо свою систему настількі просто, наскількі це Можливо, так что ее легко зрозуміті, и можна з більшою вірогідністю підтрімуваті ее в коректний стані. Це відносіться як до вісокорівневіх проектування, так и до реалізації. Наша розробка дозволяє структурно унікнуті відоміх проблем, таких як вічерпання ресурсів. При потребі ми явно обмінюємо ресурси та ефективність на Надійність. Наприклад, в ядрі статично оголошуються ВСІ структурованих даніх вместо того, щоб дінамічно віділяті пам'ять при необхідності. Хочай Ми можемо недоіспользовать Деяк пам'ять, цею підхід є Дуже пробачимо и Ніколи НЕ виробляти до помилок. Іншім прикладом є ті, что мі навмісне НЕ реалізувалі нитки. Може буті, мі заплатили за це Деяк ВТРАТИ ефектівності (а може буті, и ні), альо витівка не повінні турбувати про потенційніх В«станах гонокВ» (race condition) i сінхронізації, что істотно полегшує життя програмістам.
По-друге, мі розділілі свою систему на набор невеликих незалежних модулів. Використання властівостей модульності, такі як обмеження Розповсюдження збоїв, є ключовими елементом розробки Нашої системи. Шляхом полного поділу операційної системи на Модулі Ми можемо Встановити В«брандмаеріВ», крізь Які НЕ могут розповсюджуватіся помилки, что виробляти до більш надійної системи. Для Запобігання непрямого впліву збоїв в одному Модулі на який-небудь Інший модуль ми структурним чином зменшуємо їх взаємозалежність, наскількі це Можливо. У тихий випадка, коли це Неможливо через природи модулів, мі застосовуємо додаткові засоби ПІДТРИМКИ безпеки. Наприклад, файлова система поклади від драйверів прістроїв, альо вона розробляється таким чином, щоб буті готовою до ОБРОБКИ збоїв драйвера.
По-Третє, ми забезпечуємо Дотримання принципу найменшої авторізації. Хочай ізоляція збоїв допомагає стрімуваті їх Поширення, збій у повноважному Модулі все ще может віклікаті квартальна збиток. Тому ми зніжуємо рівень прівілеїв всех корістувальніцькіх процесів до гранично Припустиме мінімуму. У ядрі підтрімуються бітові МАСИВ и списки, Які візначають возможности процесів. Зокрема, є шкала допустимих вікліків ядра и список допустимих адресу призначення Повідомлень. Ця інформація зберігається в елементах табліці процесів, и того ее можна строго контролюваті, и нею просто Керувати. Інформація про авторізацію ініціюється во время завантаження системи, головного чином, на Основі конфігураційніх таблицю, створюван...
