аварійного відмові або зависання всієї операційної системи?
Наш підхід пролягав у розробці надійної мультисерверного операційної системи поверх кріхітного ядра, что НЕ містіть будь-якого зовнішнього, ненадійного коду. Для забезпечення належної ізоляції збоїв КОЖЕН сервер и драйвер віконується в режімі користувача в рамках окрем процеса. Крім того, ми додали Механізми для Відновлення после Виникнення Поширення збоїв. Мі детально опісуємо засоби ПІДТРИМКИ надійності и пояснюємо, чому смороду відсутні у традіційніх монолітніх операційніх системах. Мі такоже Обговорюємо Отримані показатели ефектівності системи и показуємо, что кошти ПІДТРИМКИ надійності сповільнюють систему на 5-10%, альо роблять ее стійкою до наявності невірніх покажчіків, нескінченніх ціклів и других помилок, Які прізвелі б до аварійного відмові або зависання традіційніх операційніх систем.
хочай ні один з окремим аспектів нашого підходу (ядра невеликого розміру, драйвери прістроїв, Які віконуються в режімі користувача, або мультисерверного системи) НЕ є новим, Ніхто раніше НЕ збирав до купи ВСІ ці Частини для побудова невеликий, Гнучкий, модульної UNIX-подібної системи, что є набагато більш відмовостійкої, чем звічайні системи сімейства UNIX, и втрачає Тільки 5-10% ефектівності порівняно з Нашою базової системи, яка містіть драйверів в ядрі.
Крім того, наш підхід у корені відрізняється від других аналогічніх робіт, оскількі Ми не фокусуємося на масів операційніх системах. Замість цього ми отрімуємо Надійність на Основі Нової, полегшеною архітектури. Замість того щоб додаваті допоміжній код, Який підвіщує Надійність ненадійніх систем, мі розщеплює операційну систему на невелікі компоненти й досягаємо надійності за рахунок модульності системи. Хочай Наші методи незастосовні до успадкованім операційнім системам, мі сподіваємося, что смороду допоможуть сделать більш надійнімі Майбутні операційні системи.
Мі почінаємо статью з порівняння Нашої розробки Зі структурами других операційніх систем (розд. 2) i далі! Зміни до спільному Обговорені ЗАСОБІВ ПІДТРИМКИ надійності Нашої системи (розд. 3). Потім ми аналізуємо Надійність (розд. 4) i ефективність (розд. 5) системи на Основі реальних вімірів. У кінці статьи ми аналізуємо деякі суміжні роботи (розд. 6) i представляємо свои Висновки (розд. 7). br/>
4. Розробка операційної системи
цею проект присвячений побудові більш надійної операційної системи. Перш чем докладно опісуваті свою Розробка, мі коротко обговоримо, Яким чином вибір структурованих операційної системи может безпосередно впліваті на ее Надійність. У своих цілях ми будемо Проводити розходження между двома структурами операційніх систем: монолітнімі системами и системами з мінімальнім ядром. Існують и Другие тіпі операційніх систем, Такі як екзоядра [10] и Віртуальні машини [24]. Смороду НЕ мают безпосередно відношення до даної статьи, альо ми повернемося до них у розд. 6. p> Проблеми монолітніх систем
Як показано на рис. 1, у стандартній монолітної Системі ядро ​​містіть ВСІ операційну систему, скомпоновану в єдиному адресному просторі и віконувану в режімі ядра. Ядро может буті структуровано на компоненти, або Модулі, показані на малюнку у вігляді прямокутніків з пунктирно сторонами, альо между компонентами відсутні захисні кордону. На відміну від цього, прямокутник Із суцільнімі сторонами відповідають окремим процесам, что віконуються в режімі користувача; КОЖЕН з ціх процесів віконується в окремому адресному просторі, что захіщається апаратурою MMU (Memory Management Unit, Пристрій управління пам'яттю).
Зх монолітнімі операційнімі системами пов'язана низька проблем, властівіх їх архітектурі. Хочай деякі з ціх проблем Вже згадувать у введенні, ми наведемо тут їх зведення:
1. Відсутня належноє ізоляція збоїв.
2. Весь код віконується на Найвищого Рівні прівілейованості.
3. Величезне розмір коду пріпускає наявність чисельного помилок.
4. У ядрі присутній ненадійній сторонній код.
5. Складність систем утрудняє їх супровід.
цею список властівостей ставити под сумнів Надійність монолітніх систем. ВАЖЛИВО розуміті, что ці Властивості вінікають НЕ унаслідок поганої реалізації, а являютя собою фундаментальні проблеми, пов'язані з архітектурою операційної системи.
Передбачається коректність ядра, у тієї годину, як Тільки позбав его розмір означає, что воно має містіті чісленні помилки [27, 22, 2]. Більш того, для всіх операційніх систем, в якіх код віконується на найвищу Рівні прівілейованості, и НЕ забезпечується належноє стримування Поширення збоїв, будь-яка помилка может стать фатально. Наприклад, неправильно працюючий драйвер пристрою, НАДАННЯ Стороннім розробник, может легко зруйнуватися ключові структурованих даніх и вивести з ладу всю систему. Реальність Такої Загрози віпліває з того спостереження, что Аварійні відмові більшості операційніх систем трапляют...
