Монолитное ядро - Ism-06-2.ru

Микроядро или монолит?
МАРТ
21
Автор: Революционный Матрос Железняк
Рубрики: μ-kernel, minix
Minix 3 - это микроядерная ОС. Ее ядро обслуживает прерывания, диспетчиризацию процессов,
межпроцессное взаимодействие и все. Все! Всего около 4000 строк кода на C, и 800 на
ассемблере. Все остальное, включая драйверы устройств работает в пользовательском
пространстве памяти, и ни один из этих процессов не имеет привилегий суперпользователя…
Бурные дискуссии о том, что же лучше, микроядерная или модульно-монолитная архитектура
операционных систем, не утихают и по сей день. Различия между ними таковы: ядра ОС на
основе монолитной архитектуры содержат в себе все необходимое для работы системы.
Применительно к ОС с монолитными ядрами можно сказать, что ядро системы и является самой
системой. В то время как ядра микроядерных ОС представляют собой скорее набор абстракций,
которые не составляют ОС сами по себе, но позволяют реализовать ОС в виде серверов, которые
будут использовать предоставляемые микроядром сервисы. Самые популярные из современных
операционных систем, такие как Linux, *BSD и, отчасти, Windows NT/2k,/XP основаны на
модульно-монолитной архитектуре.
У Minix 3 есть интересная особенность. Один из процессов, работающих в пользовательском
пространстве называется сервером реинкарнаций. Он хранит в памяти таблицу процессов, и
постоянно отслеживает их состояние. Если один из процессов станет работать некорректно, он
просто перезапустит его, решив тем самым, как надеются разработчики, проблему. Но скорее
всего все будет не совсем так. Как сказал один товарищ: - Вы увидите только бесконечные
сообщения о реинкарнации, скажем, сбойного драйвера диска, но работать этот драйвер по
прежнему не будет :-)
Среди очевидных преимуществ микроядерного подхода называют прежде всего
масштабируемость и отказоустойчивость. Давайте оставим в стороне первое, так как
теоритически оно вполне верно, и перейдем к критическому рассмотрению второго.
Э. Таненбаум, в дискуссиях по поводу микроядра, очень любит оперировать статистикой, говоря
что в среднем, на 1000 строк кода приходится от 6 до 16 ошибок, следовательно количество
ошибок в ядре Linux составляет около 15000, а в Windows XP - вдвое больше. Однако,
существует ложь, большая ложь, и статистика, как третья, самая большая разновидность лжи :-)
Честно говоря, в утверждение о наличие в ядре Linux пятнадцати тысяч (!) багов после всех
отладок, верится с трудом. Разумеется легко найти ошибки в 4000 тысячах строк кода ядра в
Minix, но самое главное в микроядерных ОС - это реализация межпроцессного взаимодействия
(IPC), вот что действительно становится головной болью для программистов. По словам одного из
разработчиков коммерческой микроядерной ОС (вероятно QNX), - Ядра ОС, по большей части,
вызывают отказы из-за взаимоблокировки процессов, а в случае микроядерной архитектуры
проблема становится гораздо более сложной.
Не всегда красивые теории, которые мы слышим с кафедры университета, подтверждаются в
реальном мире. А еще говорят, что удел дилетантов - учить других.
Понятие микроядра
Микроядро реализует базовые функции операционной системы, на которые опираются
другие системные службы и приложения. Основной проблемой при конструировании
микроядерной ОС является распознавание тех функций системы, которые могут быть
вынесены из ядра. Такие важные компоненты ОС как файловые системы, системы
управления окнами и службы безопасности становятся периферийными модулями,
взаимодействующими с ядром и друг с другом.
Когда-то казалось, что многоуровневая архитектура ядра ОС UNIX является вершиной в
области конструирования операционных систем. Основные функциональные компоненты
операционной системы - файловая система, взаимодействие процессов (IPC - interprocess
communications), ввод-вывод и управление устройствами - были разделены на уровни,
каждый из которых мог взаимодействовать только с непосредственно примыкающим к
нему уровнем.
Несмотря на неплохие практические результаты такая структура теперь все больше
воспринимается монолитной, поскольку вся операционная система связана иерархией
уровней. Множественность и нечеткость интерфейсов между уровнями затрудняет
модификацию системы; для этого требуется хорошее знание операционной системы,
масса времени и элемент везения.
В микроядерных архитектурах вертикальное распределение функций операционной
системы заменяется на горизонтальное. Компоненты, лежащие выше микроядра,
используют средства микроядра для обмена сообщениями, но взаимодействуют
непосредственно. Микроядро лишь проверяет законность сообщений, пересылает их
между компонентами и обеспечивает доступ к аппаратуре.
Это свойство микроядерных систем позволяет естественно использовать их в
распределенных средах. При получении сообщения микроядро может его обработать или
переслать другому процессу. Поскольку для микроядра безразлично, поступило ли
сообщение от локального или удаленного процесса, подобная схема передачи сообщений
является удобной основой удаленных вызовов процедур (RPC - Remote Procedure Calls).
Однако пересылка сообщений производится медленнее обычных вызовов функций;
оптимизация пересылки сообщений является критическим фактором успеха
микроядерной операционной системы. Например, в ОС Windows NT в некоторых случаях
для оптимизации используется разделяемая память. Расходы на дополнительную
фиксированную память микроядра оправдываются повышением эффективности передачи
сообщений.
Поскольку вся машинно-зависимая часть ОС изолирована в микроядре, для переноса
системы на новый процессор требуется меньше изменений и эти изменения логически
сгруппированы. При имеющемся разнообразии на рынке процессоров способность
операционной системы работать на разных процессорах является единственной
возможностью убедить пользователей покупать новые машины.
Расширяемость также является необходимым свойством современных операционных
систем. В отличие от аппаратных средств, которые устаревают за несколько лет,
операционные системы могут с пользой эксплуатироваться в течение десятилетий. В
жизни каждой операционной системы настает момент, когда в нее требуется внести
функции, не заложенные в исходную конструкцию. Микроядерная организация
операционных систем позволяет добиться возможности производства управляемых и
надежно работающих расширений на основе ограниченного набора четко определенных
интерфейсов микроядра.
В действительности, правильнее говорить не только о расширяемости, но и о
масштабируемости микроядерных ОС с возможностью получения варианта операционной
системы, в наилучшей степени соответствующей особенностям аппаратной платформы и
прикладной области. Микроядерная организация ОС позволяет легко добиться и этого
качества.
Одной из проблем традиционно организованных операционных систем является наличие
множества интерфейсов прикладного программирования (API - Application Programming
Interface), не все из которых хорошо документированы. В результате невозможно
гарантировать правильность программ, использующих несколько API, и даже
правильность работы самой операционной системы.
Микроядро, обладающее небольшим набором API (микроядро OSF обеспечивает около
200 системных вызовов, а крохотное микроядро QNS - всего лишь 14), увеличивает шансы
получения качественных программ. Конечно, этот компактный интерфейс облегчает
жизнь только системных программистов; прикладной программист по прежнему должен
бороться с сотнями вызовов.
Основным принципом организации микроядерных ОС является включение в состав
микроядра только тех функций, которые абсолютно необходимо выполнять в режиме
супервизора и в защищенной памяти. Обычно в микроядро включаются машиннозависимые программы (включая поддержку мультипроцессорной работы), некоторые
функции управления процессами, обработка прерываний и поддержка пересылки
сообщений.
Во многих случаях в микроядро включается функция планирования процессов, но в
реализации Mach компании IBM планировщик процессов размещен вне микроядра, а
микроядро используется только для непосредственного управления процессами. Конечно,
при этом требуется тесное взаимодействие внешнего планировщика и входящего в состав
ядра диспетчера.
В некоторых реализациях (например, в реализации OSF) в микроядро помещаются
драйверы устройств. В реализациях IBM и Chorus драйверы размещаются вне микроядра,
но для регулирования режимов разрешения и запрещения прерываний часть программы
драйвера выполняется в пространстве ядра. В NT драйверы устройств и другие функции
ввода-вывода выполняются в пространстве ядра, но реально используют ядро только для
перехвата и передачи прерываний. Следует заметить, что оба подхода допускают
динамическое подключение драйверов к системе и их отключение.
Однако имеются другие доводы в пользу выделения драйверов из состава микроядра.
Например, поскольку во многих случаях драйверы могут не зависеть от особенностей
аппаратуры, такой подход облегчает переносимость системы.
Примеры микроядерных реализаций ОС UNIX
Коротко охарактеризуем некоторые варианты ОС UNIX, построенные на основе
технологии микроядра.
OSF-1 компании Open Software Foundation
ОС OSF/1 1.3 основана на микроядре Mach. IBM является членом OSF, и эти компании
обменивались технологиями организации микроядра. Однако по некоторым важным
направлениям подходы IBM и OSF различаются. В версии 1.3 весь сервер OSF/1 работает
в пользовательском пространстве и использует функции Mach.
Почему же OSF решилась на микроядерную реализацию монолитного сервера UNIX? Как
говорят специалисты, OSF, OSF/1 является слишком хорошей и надежной системой,
чтобы можно было ее бросить и начать все сначала. В OSF/1 1.3 используется более 90%
кода предыдущих версий OSF/1. С другой стороны, чтобы улучшить возможности
управления объектами, часть ядра Mach была переписана на Си++.
В результате OSF/1 1.3 получилась не такой модульной, как ОС Workplace. Но
использовав значительную часть OSF/1, компания OSF смогла раньше IBM получить
более или менее полную микроядерную реализацию системы.
MiX компании Chorus Systems
Существует несколько реализаций микроядра Chorus. Chorus/MiX, версия компании
Chorus операционной системы с интерфейсами UNIX, включает отдельные версии,
совместимые с SVR3.2 и SVR4. USL собирается объявить Chorus/MiX V.4 микроядерной
реализацией SVR4. USL и Chorus Systems планируют совместную работу по разработке
Chorus/MiX V.4 в качестве будущего направления UNIX. Специально для использования
на персональных компьютерах компания Chorus поддерживает реализацию Chorus/MiX,
совместимую с SCO.
Hurd Free Software Foundation
Операционная система Hurd на протяжении последних нескольких лет разрабатывается в
Фонде свободного программного обеспечения (Free Software Foundation). По своему
замыслу ОС Hurd должна была явиться последней точкой в реализации проекта GNU проекта полной свободно распространяемой совместимой с ОС UNIX среды.
В числе основных разработчиков FSF исторически не было специалистов по внутренней
организации операционных систем. В частности, поэтому при реализации Hurd был
выбран подход, основанный на предоставленной университетом Карнеги-Меллон версии
микроядра Mach, а также использовании готовой файловой системы из Висконсинского
университета. Над микроядром в пользовательском режиме дописан набор серверов,
которые, однако, в отличие от OSF1 и MiX, не реализуют напрямую возможностей
системных вызовов UNIX. Реализация аналога системных вызовов выполнена в виде
набора библиотечных подпрограмм, выполняемых в адресных пространствах
пользовательских процессов.
ОС Hurd еще не выпущена в свет, хотя уже более года назад в ее среде работал shell,
emacs, GCC и другие компоненты программного обеспечения GNU. Кроме того, пока
Hurd будет доступен только на платформах Intel.
Монолитное ядро
[править]
Материал из Википедии — свободной энциклопедии
Моноли́тное ядро́ — классическая и, на сегодняшний день, наиболее
распространённая архитектура ядер операционных систем. Монолитные ядра
предоставляют богатый набор абстракций оборудования. Все части
монолитного ядра работают в одном адресном пространстве.
Монолитные ядра имеют долгую историю развития и усовершенствования и,
на данный момент, являются наиболее архитектурно зрелыми и пригодными к
эксплуатации. Вместе с тем, монолитность ядер усложняет их отладку,
понимание кода ядра, добавление новых функций и возможностей, удаление
«мёртвого», ненужного, унаследованного от предыдущих версий, кода.
«Разбухание» кода монолитных ядер также повышает требования к объёму
оперативной памяти, требуемому для функционирования ядра ОС. Это делает
монолитные ядерные архитектуры мало пригодными к эксплуатации в
системах, сильно ограниченных по объёму ОЗУ, например, встраиваемых
системах, производственных микроконтроллерах и т. д.
Альтернативой монолитным ядрам считаются архитектуры, основанные на
микроядрах.
Старые монолитные ядра требовали перекомпиляции при любом изменении
состава оборудования. Большинство современных ядер позволяют во время
работы динамически подгружать модули, выполняющие части функции ядра.
Такие ядра называются модульными ядрами. Возможность динамической
подгрузки модулей не нарушает монолитности архитектуры ядра, так как
динамически подгружаемые модули загружаются в адресное пространство
ядра и в дальнейшем работают как интегральная часть ядра. Не следует
путать модульность ядра с гибридной или микроядерной архитектурой.
Достоинства: скорость работы, упрощённая разработка модулей.
Недостатки: поскольку всё ядро работает в одном адресном пространстве,
сбой в одном из компонентов может нарушить работоспособность всей
системы.
Ядро операционной системы
Интересно |
Это центральная часть операционной системы, обеспечивающая приложениям координированный
доступ к ресурсам компьютера, таким как процессорное время, оперативная память, внешнее
оборудование. Обычно предоставляет сервисы файловой системы.
Как основопологающий элемент ОС, ядро представляет собой наиболее низкий уровень
абстракции для доступа приложений к ресурсам системы, необходимым для его работы. Как
правило, ядро предоставляет такой доступ исполняемым процессам соотвествующих приложений
за счет использования механизмов межпроцессного взаимодействия и обращения приложений к
системным вызовам ОС.
Типы архитектур ядер операционных систем
Старые монолитные ядра требовали перекомпиляции при любом изменении состава оборудования.
Большинство современных ядер операционных систем позволяют во время работы подгружать
модули, выполняющие части функции ядра.
Достоинства: Скорость работы, упрощённая разработка модулей.
Недостатки: Поскольку всё ядро работает в одном адресном пространстве, сбой в одном из
компонентов может нарушить работоспособность всей системы.
В этом случае компоненты операционной системы являются не самостоятельными модулями, а
составными частями одной большой программы. Такая структура операционной системы
называется монолитным ядром (monolithic kernel). Монолитное ядро операционной системы
представляет собой набор процедур, каждая из которых может вызвать каждую. Все процедуры
работают в привилегированном режиме.
Во многих операционных системах с монолитным ядром сборка ядра, то есть его компиляция,
осуществляется отдельно для каждого компьютера, на который устанавливается операционная
система. При этом можно выбрать список оборудования и программных протоколов, поддержка
которых будет включена в ядро. Так как ядро операционной системы является единой
программой, перекомпиляция — это единственный способ добавить в него новые компоненты или
исключить неиспользуемые. Следует отметить, что присутствие в ядре лишних компонентов
крайне нежелательно, так как ядро операционной системы всегда полностью располагается в
оперативной памяти. Кроме того, исключение ненужных компонентов повышает надежность
операционной системы в целом.
Монолитное ядро — старейший способ организации операционных систем. Примером систем с
монолитным ядром является большинство Unix-систем.
В монолитном ядре выделяются вкрапления сервисных процедур, соответствующих системным
вызовам. Сервисные процедуры выполняются в привилегированном режиме, тогда как
пользовательские программы — в непривилегированном. Для перехода с одного уровня
привилегий на другой иногда может использоваться главная сервисная программа,
определяющая, какой именно системный вызов был сделан, корректность входных данных для
этого вызова и передающая управление соответствующей сервисной процедуре с переходом в
привилегированный режим работы.
Если в ОС с таким ядром вылетит какой-либо процесс, то он может быть автоматически
перезапущен, а с цельным ядром в случае вылетания процесса, входящего в состав ядра, надо
перезапускать всё ядро. Многие владельцы телефонов с Symbian OS, основанной на микроядре,
сталкивались с этим: слетает какой-нибудь процесс (на экране появляется сообщение «Прилож.
закр.: имя»), а затем этот процесс автоматически перезапускается как ни в чём не бывало.
В частности, монолитное ядро операционной системы более производительно, чем микроядро,
поскольку состоит не из множества разрозненных процессов, «общающихся» между собой, а
работает как один большой процесс.
Монолитным ядром является еще и Linux. Оно оптимизировано для более высокой
производительности с минимальными контекстными переключениями. Такая архитектура
упрощает поддержку кода ядра для разработчиков, но требует перекомпиляции ядра при
добавлении новых устройств. Следует отметить, что описанные здесь различия являются
«классическими», на практике монолитные ядра могут поддерживать модульность (что зачастую и
происходит), а микроядра могут требовать перекомпиляции.
Примеры: Традиционные ядра UNIX(сетевые операционные системы), такие как BSD и Linux;
ядро MS-DOS.
Модульное ядро — современная, усовершенствованная модификация архитектуры монолитных
ядер операционных систем компьютеров.
В отличие от «классических» монолитных ядер, считающихся ныне устаревшими, модульные ядра,
как правило, не требуют полной перекомпиляции ядра при изменении состава аппаратного
обеспечения компьютера. Вместо этого модульные ядра предоставляют тот или иной механизм
подгрузки модулей ядра, поддерживающих то или иное аппаратное обеспечение (например,
драйверов). При этом подгрузка модулей может быть как динамической (выполняемой «на лету»,
без перезагрузки ОС, в работающей системе), так и статической (выполняемой при перезагрузке
ОС после переконфигурирования системы на загрузку тех или иных модулей).
Все модули ядра работают в адресном пространстве ядра и могут пользоваться всеми функциями,
предоставляемыми ядром. Поэтому модульные ядра продолжают оставаться монолитными.
Модульные ядра предоставляют особый программный интерфейс (API) для связывания модулей с
ядром, для обеспечения динамической подгрузки и выгрузки модулей. В свою очередь, не любая
программа может быть сделана модулем ядра: на модули ядра накладываются определённые
ограничения в части используемых функций (например, они не могут пользоваться функциями
стандартной библиотеки С/С++ и должны использовать специальные аналоги, являющиеся
функциями API ядра). Кроме того, модули ядра обязаны экспортировать определённые функции,
нужные ядру для правильного подключения и распознавания модуля, для его корректной
инициализации при загрузке и корректного завершения при выгрузке, для регистрации модуля в
таблице модулей ядра и для обращения из ядра к сервисам, предоставляемым модулем.
Не все части ядра операционной системы могут быть сделаны модулями. Некоторые части ядра
всегда обязаны присутствовать в оперативной памяти и должны быть жёстко «вшиты» в ядро.
Также не все модули допускают динамическую подгрузку (без перезагрузки ОС). Степень
модульности ядер (количество и разнообразие кода, которое может быть вынесено в отдельные
модули ядра и допускает динамическую подгрузку) различна в различных архитектурах модульных
ядер. Ядро «Linux» в настоящее время имеет более модульную архитектуру, чем ядра *BSD
(FreeBSD, NetBSD, OpenBSD).
Общей тенденцией развития современных модульных архитектур является всё большая
модуларизация кода (повышение степени модульности ядер), улучшение механизмов
динамической подгрузки и выгрузки, уменьшение или устранение необходимости в ручной
подгрузке модулей или в переконфигурации ядра при изменениях аппаратуры путём введения тех
или иных механизмов автоматического определения оборудования и автоматической подгрузки
нужных модулей, универсализация кода ядра и введение в ядро абстрактных механизмов,
предназначенных для совместного использования многими модулями (примером может служить
VFS — «виртуальная файловая система», совместно используемая многими модулями файловых
систем в ядре Linux).
Микроядро предоставляет только элементарные функции управления процессами и минимальный
набор абстракций для работы с оборудованием. Бо́льшая часть работы осуществляется с помощью
специальных пользовательских процессов, называемых сервисами.
Достоинства: Устойчивость к сбоям оборудования, ошибкам в компонентах системы.
Недостатки: Передача данных между процессами требует накладных расходов.
Остальные компоненты системы взаимодействуют друг с другом путем передачи сообщений через
микроядро.
Основное достоинство микроядерной архитектуры — высокая степень модульности ядра
операционной системы. Это существенно упрощает добавление в него новых компонентов. В
микроядерной операционной системе можно, не прерывая ее работы, загружать и выгружать
новые драйверы, файловые системы и т. д. Существенно упрощается процесс отладки
компонентов ядра, так как новая версия драйвера может загружаться без перезапуска всей
операционной системы. Компоненты ядра операционной системы ничем принципиально не
отличаются от пользовательских программ, поэтому для их отладки можно применять обычные
средства. Микроядерная архитектура повышает надежность системы, поскольку ошибка на уровне
непривилегированной программы менее опасна, чем отказ на уровне режима ядра.
И чтобы добавить в ОС с микроядром драйвер того или иного устройства, не надо
перекомпилировать всё ядро, а надо лишь отдельно откомпилировать этот драйвер и запустить
его в пользовательском пространстве.
В то же время микроядерная архитектура операционной системы вносит дополнительные
накладные расходы, связанные с передачей сообщений, что отрицательно влияет на
производительность. Для того чтобы микроядерная операционная система по скорости не уступала
операционным системам на базе монолитного ядра, требуется очень аккуратно проектировать
разбиение системы на компоненты, стараясь минимизировать взаимодействие между ними. Таким
образом, основная сложность при создании микроядерных операционных систем — необходимость
очень аккуратного проектирования.
Примеры: QNX; Mach, используемый в GNU/Hurd и MacOS X; AIX; Minix ; ChorusOS ; AmigaOS;
MorphOS.
Экзоядро — ядро операционной системы компьютеров, предоставляющее лишь функции для
взаимодействия между процессами и безопасного выделения и освобождения ресурсов.
Наноядро — архитектура ядра операционной системы компьютеров, в рамках которой крайне
упрощённое и минималистичное ядро выполняет лишь одну задачу — обработку аппаратных
прерываний, генерируемых устройствами компьютера. После обработки прерываний от
аппаратуры наноядро, в свою очередь, посылает информацию о результатах обработки (например,
полученные с клавиатуры символы) вышележащему программному обеспечению при помощи того
же механизма прерываний. Примером является KeyKOS - самая первая ОС на наноядре. Первая
версия вышла ещё в 1983-ем году.
Гибридные ядра это модифицированные микроядра, позволяющие для ускорения работы
запускать «несущественные» части в пространстве ядра.
Имеют «гибридные» достоинства и недостатки.
Существуют варианты ОС GNU, в которых вместо монолитного ядра применяется ядро Mach (такое
же, как в Hurd), а поверх него крутятся в пользовательском пространстве те же самые процессы,
которые при использовании Linux были бы частью ядра. Другим примером смешанного подхода
может служить возможность запуска операционной системы с монолитным ядром под
управлением микроядра. Так устроены 4.4BSD и MkLinux, основанные на микроядре Mach.
Микроядро обеспечивает управление виртуальной памятью и работу низкоуровневых драйверов.
Все остальные функции, в том числе взаимодействие с прикладными программами,
осуществляется монолитным ядром. Данный подход сформировался в результате попыток
использовать преимущества микроядерной архитектуры, сохраняя по возможности хорошо
отлаженный код монолитного ядра.
Определение операционных систем и их
классификация
В предыдущем подразделе было отмечено, что предоставляемые
пользователям ресурсы компьютера определяют его архитектуру, а система команд
предоставляет возможности по управлению и использованию этих ресурсов. Однако
управление компьютером на уровне системы команд достаточно сложно, поскольку
требует от пользователя досконального знания не только особенностей, но и
тонкостей аппаратурной реализации его подсистем и устройств внешнего
окружения. Такое управление ещё и малоэффективно, так как каждый пользователь
должен кроме прикладных программ разрабатывать стандартные процедуры ввода и
вывода данных, отображения результатов вычислений, управления внутренними и
внешними ресурсами компьютера и другие. Операционная система является
программной надстройкой над архитектурой компьютера, которая обеспечивает
удобный пользовательский интерфейс, берет на себя функции автоматического
управления рядом его подсистем и предоставляет готовые процедуры управления
внутренними и внешними ресурсами. То есть, операционная система является
некоей автоматизированной системой управления работой и ресурсами компьютера,
повышающая удобство и эффективность его использования.
Операционные системы (ОС) классифицируют:

по особенностям алгоритмов управления ресурсами – локальные и
сетевые ОС. Локальные ОС управляют ресурсами отдельного компьютера.
Сетевые ОС участвуют в управлении ресурсами сети;

по числу одновременно выполняемых задач - однозадачные и
многозадачные. Однозадачные ОС выполняют функцию предоставления
пользователю виртуальной вычислительной машины, обеспечивая его
простым и удобным интерфейсом взаимодействия с компьютером,
средствами управления периферийными устройствами и файлами.
Многозадачные ОС, кроме вышеперечисленных функций, управляют
разделением совместно используемых ресурсов, таких как процессор,
оперативная память, файлы и внешние устройства;

по числу одновременно работающих пользователей однопользовательские и многопользовательские. Основным отличием
многопользовательских систем от однопользовательских является наличие
средств защиты информации каждого пользователя от несанкционированного
доступа других пользователей;
по возможности распараллеливания вычислений в рамках одной
задачи - поддержка многонитевости. Многонитевая ОС разделяет
процессорное время не между задачами, а между их отдельными ветвями –
нитями;


по способу распределения процессорного времени между
несколькими одновременно существующими в системе процессами или
нитями - невытесняющая многозадачность и вытесняющая
многозадачность. В невытесняющей многозадачности механизм
планирования процессов целиком сосредоточен в операционной системе, а в
вытесняющей распределен между системой и прикладными программами.
При невытесняющей многозадачности активный процесс выполняется до тех
пор, пока он сам по собственной инициативе не передаст управление
операционной системе для выбора из очереди другого готового к
выполнению процесса. При вытесняющей многозадачности решение о
переключении процессора с одного процесса на другой принимается
операционной системой, а не самим активным процессом;

по отсутствию или наличию в ней средств поддержки
многопроцессорной обработки. Многопроцессорные ОС, в свою очередь,
могут классифицироваться по способу организации вычислительного
процесса в системе с многопроцессорной архитектурой: асимметричные ОС
и симметричные ОС. Асимметричная ОС целиком выполняется только на
одном из процессоров системы, распределяя прикладные задачи по
остальным процессорам. Симметричная ОС полностью децентрализована и
использует весь набор процессоров, разделяя их между системными и
прикладными задачами;

по ориентации на аппаратные средства - операционные системы
персональных компьютеров, серверов, мейнфреймов, кластеров;
по зависимости от аппаратных платформ – зависимые и
мобильные. В мобильных ОС аппаратно зависимые места локализованы так,
что при переносе системы на новую платформу переписываются только они.
Средством, облегчающим перенос ОС на другой тип компьютера является
написание ее на машинно-независимом языке, например, на С;

по особенностям областей использования – ОС пакетной
обработки, разделения времени, реального времени. Системы пакетной
обработки предназначены для решения задач вычислительного характера, не
требующих быстрого получения результатов. Главной целью и критерием
эффективности систем пакетной обработки является максимальная
пропускная способность, то есть решение максимального числа задач в
единицу времени. В системах с разделением времени каждому пользователю
предоставляется терминал, с которого он может вести диалог со своей
программой. Каждой задаче выделяется некоторый квант процессорного
времени, так что ни одна задача не занимает процессор надолго. Если квант
времени выбран небольшим, то у всех пользователей, одновременно
работающих на одном компьютере, создается впечатление, что каждый из
них единолично использует машину. Системы реального времени
применяются для управления различными техническими объектами, когда
существует предельно допустимое время, в течение которого должна быть
выполнена та или иная программа управления объектом. Невыполнение
программы в срок может привести к аварийной ситуации. Таким образом,
критерием эффективности систем реального времени является их
способность выдерживать заранее заданные интервалы времени между
запуском программы и получением результата - управляющего воздействия;



по структурной организации и концепциям, положенным в основу:
по способу построения ядра системы - монолитное ядро или
микроядерный подход. ОС использующие монолитное ядро, компонуются как одна
программа, работающая в привилегированном режиме и использующая быстрые
переходы с одной процедуры на другую, не требующие переключения из
привилегированного режима в пользовательский и наоборот. При построении ОС на
базе микроядра, работающего в привилегированном режиме и выполняющего
только минимум функций по управлению аппаратурой, функции более высокого
уровня выполняют специализированные компоненты ОС – программные серверы,
работающие в пользовательском режиме. При таком построении ОС работает более
медленно, так как часто выполняются переходы между привилегированным
режимом и пользовательским, но система получается более гибкой и ее функции
можно модифицировать, добавляя или исключая серверы пользовательского
режима;

по построению на базе объектно-ориентированного подхода;

по наличию нескольких прикладных сред в рамках одной ОС,
позволяющих выполнять приложения, разработанные для нескольких
операционных систем. Концепция множественных прикладных сред наиболее
просто реализуется в ОС на базе микроядра, над которым работают различные
серверы, часть которых реализуют прикладную среду той или иной операционной
системы;

по распределению функций операционной системы среди
компьютеров сети. В распределенной ОС реализованы механизмы,
обеспечивающие пользователя возможностью представлять и воспринимать сеть в
виде однопроцессорного компьютера. Признаками распределенной ОС является
наличие единой справочной службы разделяемых ресурсов и службы времени,
использование механизма вызова удаленных процедур для распределения
программных процедур по машинам, многонитевой обработки, позволяющей
распараллеливать вычисления в рамках одной задачи и выполнять эту задачу
одновременно на нескольких компьютерах сети, а также наличие других
распределенных служб.

Микроядро L4 как основа ядра ОС



0. От автора.

Данная статья прежде всего о перспективах использования L4 в качестве основы
для написания ядра OS/2. А также, кроме реализации OS/2 API, цель состоит в
интеграции "чужих" API. "Чужие" API, вместе с собственно API ядра OS/2,
предлагается реализовать параллельно поверх того же микроядра. За основу взята
схема OS/2 Warp PowerPC Edition, реализованная в начале 1990-х гг фирмой IBM.
Текст получился достаточно объемным. -- В двух словах об этом рассказать
невозможно; о многих обсуждаемых здесь технологиях большинство не слышало и
о реальном положении дел с микроядрами многие имеют устаревшее
представление; многое за последние 10 лет сильно изменилось. Акцентирую ваше
внимание на главе "Обзор проектов на базе микроядра L4". Она содержит
технологии, которые содержат важные идеи и могут являться основой для
реализации API. Глава "Планы на будущее" содержит общую схему, в которую
входит OS/2 API вместе с API Linux и прочими API. Также полезно для понимания
событий, происходящих последние 20 лет в разработке микроядерных ОС,
прочитать главы "История вопроса. Понятие микроядра и проблема
производительности." и "Реализации L4". Если вам неинтересны технические
подробности и внутренности микроядра, то теоретический экскурс в механизмы и
API L4 и последующие главы, можно пропустить. Надеюсь, статья будет вам
полезной, заинтересует и поможет в выборе основы для будущего ядра и подхода в
реализации API.

1. История вопроса. Понятие микроядра и проблема
производительности.

Традиционные операционные системы, в том числе, OS/2 и UNIX, в их нынешнем
виде, представляют собой классические монолитные ядра. То есть, управление
памятью, файловая система, планировщик процессов, драйвера -- все эти службы
были собраны в один большой кусок исполняемого кода, исполняющийся с
максимальными привилегиями. Несмотря на то, что во многих таких системах
были также и подключаемые драйверы в виде отдельных файлов, это по-прежнему
был монолит, в котором каждый компонент, если в нем возникает ошибка, мог





испортить состояние всей системы. -- Все мы знаем ситуацию, когда драйвер
может "трапнуть" систему и помогает только перезагрузка.
Уже в 70-х гг. разработчики UNIX столкнулись с проблемой расширяемости
монолитного ядра. Увеличивался объем кода в ядре, каждый компонент которого
мог испортить другой компонент и мог напрямую менять структуры данных
других компонентов. Это усложняло структуру связей между компонентами ядра
ОС; взаимодействия между компонентами были очень сложными, и поэтому
отлавливать ошибки было очень сложно. Также это было плохо в плане
модульности -- трудно отделить какой-нибудь компонент ядра и заменить его на
другой компонент.
Эти недостатки были частично решены созданием загружаемых драйверовмодулей. Но все равно, оставались проблемы модульности, безопасности и
устойчивости. Все это потому, что:
1) ядро очень большое, в нем велика вероятность ошибок
2) компоненты ядра исполняются в одном адресном пространстве и имеют доступ к
структурам друг друга
3) они исполняются на высшем уровне привилегий, поэтому могут сделать что
угодно, в том числе, испортить систему
4) взаимоотношения между компонентами ОС не ограничены; каждый компонент
может менять структуры данных других компонентов
Все эти проблемы решаемы, если:
1) вынести все ненужное из ядра
2) разнести все компоненты по разным адресным пространствам
3) вынести их на пользовательский уровень привилегий
4) разделить систему на множество компонентов со строго заданными
интерфейсами.
Ключом к этому является концепция микроядра. Микроядерный подход
существует уже долгое время, начиная с 80-х гг. 20-го столетия. Одним из первых
микроядер было микроядро Mach (Carnegie- Mellon University). Эти
исследовательские проекты были направлены на создание надежной,
производительной, безопасной, расширяемой и модульной операционной системы.
Долгое время удавалось достичь почти всех этих целей, за исключением
производительности, которая перечеркивала остальные преимущества. Первые
микроядра были очень медленными, и на тогдашнем железе были
неповоротливыми.
То есть, на микроядерные системы возлагалось очень много надежд и до
последнего времени они не оправдывались. Самым популярным микроядром было
микроядро Mach, разработанное в университете Карнеги-Меллона. На его основе
было реализовано несколько юникс-подобных систем. В том числе, большие
надежды на это микроядро возлагал проект GNU, который использовал его для
разработки своей системы HURD. Также известными примерами использования
Mach были Mac OS X (использует модифицированное микроядро Mach с обвязкой
из BSD-сервисов и драйверов -- называется это ядро Darwin); IBM Workplace OS -изначальный грандиозный план объединить на одном десктопе OS/2, AIX,
Windows, DOS, AS/400 и прочие системы. Этот план был частично реализован,
хотя и в общем закончился неудачей. Из всего этого набора OS Personalities были
реализованы только OS/2 Personality и DOS/MVM Personality. Получившийся
продукт назывался OS/2 Warp Connect (PowerPC Edition). Он был в конце концов
предложен узкому кругу клиентов IBM и широко не рекламировался и не
продавался. Эта разработка основывалась также на модифицированном микроядре
Mach с обвязкой Personality-Neutral (не зависимых от Personality) сервисами. На
основе этих сервисов были построены конкретные personalities.




Также известно, что и у компании Microsoft была попытка использовать микроядро
Mach в Windows NT 3.1.
Все эти попытки в целом закончились неудачей (за исключением MacOS X).
Главная из этих неудач -- очень низкая производительность системы. Несколько
исследовательских групп стало изучать причины низкого быстродействия
микроядер. Были разработаны компромиссные подходы. Например, в Mac OS X и
Windows NT драйверы были вновь включены внутрь ядра, что позволяло достичь
более высокой производительности. Известна также группа из MIT (США),
разработавшая в итоге этих исследований Экзоядро (Exokernel) и группа из
института GMD (Германия) под руководством профессора Йохена Лидтке (Jochen
Liedtke), разработавшего в итоге своих исследований микроядро L4. Известно
также, что Лидтке позже сотрудничал с IBM. Экзоядро и по сей день остается
очень интересной и многообещающей концепцией, но так и осталось в качестве
исследовательского проекта. Подробности опустим, но отметим, что экзоядро -более радикальный путь, чем использование микроядра. В отличие от микроядер,
экзоядра еще более минимальны. Они содержат механизмы, но не создают
примитивов, а вся ОС реализуется в userlevel в виде библиотек с API. Ядро только
разграничивает разные "Library OS". То есть, под ОС в экзоядерном подходе
понимается набор библиотек с API. [10]. В отличие от экзоядра, L4 -- это не просто
исследовательский проект, оно очень бурно развивается. Несмотря на смерть
Лидтке в 2001 году, множество его последователей продолжают исследования. На
данный момент развитие L4 уже перешло в стадию коммерческих разработок
(например, разработка коммерческой версии OKL4 от Open Kernel Labs
(Австралия), используемой в Embedded устройствах). [5]
Лидтке выдвинул множество очень плодотворных идей для построения
действительно эффективного микроядра. Выяснилось, что ключом к этому
является:
1) минимальность самогО микроядра, необходимость сохранить в ядре только
жизненно важные механизмы и примитивы.
2) зависимость самого микроядра от архитектуры машины и оптимизация под нее
3) оптимизация механизма передачи сообщений (IPC), на котором основано все
взаимодействие между частями системы
4) эффективная реализация переключения контекста процессов, в том числе,
эффективность переходов в/из ядра в пользовательский уровень.
То есть, производительность не является фундаментальным недостатком понятия
микроядра. Оказалось, что если с умом реализовать все необходимые механизмы,
то можно достичь очень высокой производительности. Я встречал в литературе
несколько общих оценок производительности микроядра для случая L4. Если
сравнивать микроядерную систему с монолитной на примере ядра Линукса,
согласно общеизвестным фактам (я видел эти цифры в нескольких популярных
статьях, в том числе, в статье Таненбаума [2] и в [15]), порт Линукса на микроядро
Mach под названием MkLinux, медленнее "родного" ядра Linux примерно на 20%.
L4Linux -- паравиртуализованая версия Linux над микроядром L4 -- медленнее
всего на 2-5%, что практически неощутимо. Заметим, еще что L4Linux не
оптимизирован под микроядерную структуру ОС. -- Это просто модифицированное
для работы в окружении L4 монолитное ядро линукса. Так что, если реализовать
мультисерверный аналог линукса, то производительность могла быть еще больше.
Еще заметим, что в отдельных случаях L4Linux может обгонять по
производительности native Linux. На заглавной странице L4HQ [7] висит новость,
что по тестам Imbench производительность переключения контекста в Wombat
(паравиртуализованная версия Linux от NICTA) для процессора XScale до 30 раз









выше, чем в "родном" линуксе, за счет оптимизации производительности
переключения контекста в Pistachio-embedded.
Известно также, что производительность механизма межпроцессного
взаимодействия (IPC -- InterProcess Communication -- в данном случае -- передача
сообщений) в L4 на 1-2 порядка превосходит производительность IPC в Mach.
(Более точные и детальные цифры можно найти в статье Лидтке "Towards Real
Microkernels" [1]). Также известно, что согласно тестам производительности, L4
обгоняет даже такую заслуженную коммерческую разработку как микроядро QNX
Neutrino. Графики с сравнением производительности L4, Mach, QNX и других
микроядер я видел в слайдах лекций по L4 Дрезденского Технического
Университета (разработчик L4/Fiasco) [3].
Что касается минимальности. Если сравнивать Mach и L4, то микроядро Mach было
очень громоздким, у него было больше сотни системных вызовов, оно содержало в
себе порядка 100000 строк кода, занимало около 500 Кбайт на диске (по крайней
мере, версия из OS/2 PPC, которая была в формате ELF и для RISC-процесора). L4
же на 1-2 порядка компактнее. Оригинальная реализация L4 содержала всего 7
системных вызовов, сложность его была порядка 10000 строк кода, на диске оно
занимает примерно 100 К (формат ELF, платформа Intel; данные для
L4Ka::Pistachio), а вот в памяти оно занимает всего 12 Кбайт! (По другим данным -32 Кбайт, это зависит от версии ядра; неясно, о какой версии велась речь). Поэтому
L4 также часто называют наноядром (nanokernel), поскольку его размер на 1-2
порядка меньше классического микроядра. Кроме того, размер исходников
L4Ka::Pistachio подо все платформы вместе -- около 8 Мб. Понятно, что только
небольшая часть этого собирается под конкретную платформу.
Также, оригинальное микроядро L4/x86, написаное Liedtke, было оптимизировано
под 486 процессор и было написано на ассемблере. Современное микроядро
L4Ka::Pistachio уже написано на C++ со вставками на ассемблере, и содержит
generic часть (независимую от архитектуры), части, специфичные для каждой
архитектуры, части, специфичные для отдельных платформ, и склеивающего кода.
То есть, присутствует оптимизация под каждую платформу и архитектуру.
Механизм передачи сообщений также был оптимизирован. Были использованы
особые ухищрения типа передачи маленьких сообщений в регистрах процессора,
передачи строк не копированием, а по ссылке и установки временной области
разделяемой памяти для случая передачи больших объемов данных.
Производительность операции IPC была достигнута настолько высокой, что время
выполнения этой операции сравнимо с временем выполнения системных вызовов в
Linux. Также, в L4 отсутствует понятие порта (канала для передачи сообщений, как
в Mach). Оно оказалось лишней сущностью, реализация которой понижала
производительность.
Ну и механизм переключения контекста тоже был оптимизирован (подробностей, к
сожалению, не знаю ;)).
2. Реализации L4 и их эволюция.
 (Этот раздел является пересказом статьи в английской Wikipedia про L4: [9])
L4 -- это не просто название микроядра, а название API и семейства микроядер,
основанных на этом API. API L4 имеет несколько различных реализаций и версий.
Основными являются на данный момент L4/Fiasco, написанное в Дрезденском
Техническом Университете (TUD, Германия, [8]) и L4Ka:Pistachio, написанное
System Architecture Group университета Карлсруэ -- Karlsruhe University (Ka). [6]
(тоже Германия).
История начинается с начала 1990-х гг.
a) L3











Оригинальное микроядро, предшественник L4. Разработано Йохеном Лидтке.
Доказало правильность идеи, заключающейся в том, что хорошо проработанный
легковесный механизм IPC в сочетании с оптимизацией ядра для конкретной
платформы дает высокий прирост производительности. L3 было очень стабильным
и производительным, и использовалось в нескольких операционных системах.
б) L4/x86 ("Lime Pip")
Версия L4, написанная Лидтке на ассемблере. Лидтке увидел, что ядро может быть
еще более минимальным, чем L3, и решил написать новое ядро, реализовав
множество улучшений в базовых механизмах и в производительности. Поэтому,
чтобы ядро было максимально производительным, он решил его написать на
ассемблере. L4 произвело революцию в разработке микроядер. Сразу множество
организаций и университетов стало изучать L4. В том числе, IBM, где Лидтке
начал работать с 1996 г. В IBM Watson Research Center Лидтке и его коллеги
продолжили изучение L4 и микроядерных систем в целом.
в)L4Ka::Hazelnut
В 1999 г. Лидтке возглавил Systems Architecture Group в университете Карлсруэ,
где он продолжил исследования микроядерных систем. Как доказательство
возможности построения высокопроизводительного микроядра на языке высокого
уровня (proof of concept), группа Ka разработала ядро L4Ka::Hazelnut. Оно было
написано на C++ и работало на архитектурах IA32 и ARM. Реализация была
успешной, производительность замечательной, и с выпуском Hazelnut разработка
ядра на ассемблере была прекращена.
г) L4/Fiasco
Параллельно с разработкой L4Ka::Hazelnut, в 1998 г. в Группе Операционных
Систем Дрезденского Технического Университета (группа TUD:OS) была начата
разработка своей реализации L4 на C++. Эта разработка была названа Fiasco. По
сравнению с L4Ka::Hazelnut и его наследником L4Ka::Pistachio, который позволяет
прерывать исполнение ядра только в определенных точках исполнения, Fiasco
является полностью вытесняемым (fully preemptible) (за исключением очень
коротких атомарных операций), что позволяет достигнуть малой задержки при
обработке прерываний (to achieve a low interrupt latency). Это было признано
необходимым, так как Fiasco используется в разработке ОС жесткого реального
времени DROPS, также разрабатываемой в TU Dresden.
д) L4Ka::Pistachio
До выпуска L4Ka::Pistachio и новейших версий Fiasco, все версии L4 были тесно
привязаны к соответствующей архитектуре процессора. Следующим большим
шагом в развитии L4 была разработка переносимого API L4, которое сохраняло
высокие характеристики производительности при условии переносимости. При
сохранении базовых концепций, новое API вводило много радикальных изменений,
улучшающих переносимость, включало поддержку многопроцессорности,
исключало тесную взаимосвязь между тредами и адресными пространствами (см.
ниже). Также, были введены user-level thread control blocks (UTCB) и виртуальные
регистры (см. ниже). Версия X.2 API, в реализации L4Ka::Pistachio, написанном с
чистого листа в 2001 году, теперь фокусируется на высокой производительности в
сочетании с переносимостью.
е) Новые версии Fiasco
Также, за эти годы большие изменения претерпело ядро Fiasco. Оно теперь
поддерживает большое число платформ, включая IA32, IA64, несколько ARMплатформ. Интересно, что была разработана версия Fiasco-UX, которая запускается
как user-level приложение Linux. Fiasco реализует ряд расширений L4 V.2 API (см.
ниже). Сообщения IPC о происходящих исключительных ситуациях (Exception
IPC) позволяют ядру сообщать user-level программам об исключительных






ситуациях процессора. Также, были добавлены UTCB, как в API X.2. Кроме этого,
Fiasco содержит ряд механизмов для управления коммуникационными правами, а
также потреблением ресурсов ядром. На основе Fiasco разработана система userlevel сервисов под названием L4Env, которая среди прочего содержит
паравиртуализованную версию Linux (версии 2.6.x), называемую L4Linux.
ж) разработки Университета Нового Южного Уэльса (UNSW) и NICTA
Также разработка шла в Университете Нового Южного Уэльса, (UNSW,
Австралия), где были реализованы версии L4 для нескольких 64-битных
архитектур. Так были разработаны L4/MIPS и L4/Alpha, после чего оригинальная
работа Лидтке была названа L4/x86. Как и оригинальная работа Лидтке, ядра
UNSW были разработаны на смеси C и ассемблера, были написаны с нуля и были
непереносимыми. С релизом L4Ka::Pistachio UNSW свернул свои разработки L4 и
вместо этого стал разрабатывать очень отлаженные порты L4Ka::Pistachio, включая
самую быструю из всех имеющихся, разработку для Itanium (36 циклов процессора
за операцию IPC). Эта группа также продемонстрировала, что драйверы в user-level
могут давать такую же производительность, как драйверы в ядре, и разработала
Wombat -- высокомобильную версию Linux для L4, работающую на архитектурах
x86, ARM и MIPS. На процессорах XScale Wombat продемонстрировал
производительность переключения контекста, в 30 раз более высокую, чем в
"родном" Linux. [7]. Группа ERTOS организации NICTA, куда перебазировались
разработчики UNSW, продолжает развивать свою версию Pistachio
(NICTA::Pistachio-embedded), направленную прежде всего на embedded и real-time
применения.
з) разработки Open Kernel Labs
NICTA создала коммерческую компанию под названием Open Kernel Labs (OK
Labs), для продвижения на рынке решений (в основном, встраиваемых) на базе L4.
OK Labs разрабатывает собственную коммерческую реализацию NICTA::Pistachioembedded, вместе с Wombat и Iguana. Эта собственная версия L4, Wombat и Iguana
носит название OKL4. "Коммерческость" OKL4 не отменяет свободности ее
лицензии. OKL4 лицензируется под BSD лицензией и ее исходники открыты.
3. Обзор проектов на базе микроядра L4.
L4 построено таким образом, что на его базе можно построить практически любой
API. Оно абстрагируется от конкретных алгоритмов управления памяти и прочих
стратегий, но предоставляет механизмы для реализации их (стратегий) в
произвольном виде. Также оно поддерживает много аппаратных платформ, имеет
поддержку многопроцессорности (SMP) в ядре. Поддерживаются драйверы в user
space и запуск одновременно нескольких ОС на одном микроядре. Кроме того,
поддерживается создание как ОС реального времени, так и обычных ОС с
разделением времени; как ОС для embedded применений, так и desktop OS; можно
реализовать различные стратегии планировщика процессов (и управления
памятью). Поддерживаются такие возможности как orthogonal persistence (пока это
еще нигде не реализовано, но базовые механизмы имеются [14]), возможность
формального доказательства правильности алгоритмов микроядра (пока не
реализовано, но работы ведутся; OK Labs обещает в течение ближайших 2-ух лет
выпустить первое микроядро с математически доказанным отсутствием ошибок
(formally-proven bug-free microkernel) [5]). Все эти возможности предопредилили
появление множества проектов операционных систем, основанных на L4. Здесь мы
попытаемся кратко описать существующие проекты, чем они могут быть нам
полезны. Прежде всего, на мой взгляд, очень важно, что все эти проекты имеют
общую базу и возможен их запуск одновременно (Запустить L4Linux и WinCE на
одном десктопе с OS/2 -- it's cool!). Хотя сейчас и существуют расхождения в API











разных реализаций микроядра, но существуют стандарты -- они принимаются и
разные реализации рано или поздно должны согласовать свой API со cтандартом.
Теперь, собственно, о проектах и их пользе для проекта по разработке ядра
операционной системы OS/2.
На данный момент существуют три крупнейших центра, разрабатывающих
микроядро L4 и проекты на его основе, их мы уже упоминали. Это Университет
Карлсруэ, Технический Университет Дрездена и австралийская организация
NICTA (в Австралийский центр по разработке L4 входят Университет Нового
Южного Уэльса (UNSW) и дочерняя фирма NICTA Open Kernel Labs). Каждый из
этих центров параллельно ведут разработки своих версий микроядра, основанных
на них userlevel служб, опреационных систем, а также средств разработки.
1) Разработки Университета Карлсруэ
Группа из Университета Карлсруэ ("группа Ka") ведет разработки на основе своего
микроядра L4Ka::Pistachio.
a) исследования в области persistence
Persistence переводится как "постоянство". (К сожалению, не знаю русского
аналога этого термина). Применительно к компьютерным системам это означает
свойство системы сохранять свое состояние после перезагрузок и крахов. Это
свойство оказывается очень важным, например, в случае очень длительных
непрерывных вычислений; Обычно в этом случае при перерыве в вычислениях
программа сама явным образом сохраняет на диск все промежуточные результаты,
чтобы потом их можно было продолжить с того же места. Полностью
ортогональная persistent система в идеале позволяет программам не заботиться о
сохранении промежуточных результатов на диске, а также позволяет пользователю
не бояться потери данных при случайном падении системы. Взамен этого, такая
система берет заботу об этом на себя, сохраняя промежуточные состояния всех
программ пользователя и всех частей системы независимо друг от друга, причем
это свойство реализуется прозрачным образом для программ, позволяя им не
заботиться о сохранении результатов своей работы.
Применительно к микроядру L4 оказывается, что для реализации orthogonal
persistence практически не требуется модификации базовых механизмов
микроядра, или же требуются только минимальные их модификации. В работе [14]
обсуждаются вопросы persistence и механизмы для ее реализации для микроядра
L4. Эти механизмы основываются на системе userlevel пейджеров (про пейджеры
см. раздел об управлении памятью).
Также, можно привести ссылку по теме: Проект Unununium (вот такое хитрое
название) [20], и хотя проект этот не имеет отношения к L4, но он имеет
отношение к попыткам реализации persistence.
Применение идеи persistence к обычным операционным системам, таким как OS/2 - интересный вопрос; пока неизвестно, можно ли эту идею интегрировать в
систему, сохранив как было прежний облик операционной системы.
б) технологии виртуализации
Также, большой проект группы L4Ka занимается исследованиями в области
применения L4 в качестве основы для системы виртуальных машин. Подобно
применению гипервизора Xen [21], L4 также может служить гипервизором,
запуская несколько гостевых операционных систем в виртуальных машинах. Эти
виртуальные машины не занимаются эмуляцией на уровне инструкций процессора,
как виртуальные машины типа VirtualPC, а только ограничивают набор ресурсов,
доступных гостевой операционной системе (объем памяти, набор доступных
устройств и т. п.), а также используют технологию паравиртуализации.
Паравиртуализация -- это модификация гостевой операционной системы таким
образом, чтобы она работала не с реальным оборудованием, а с абстракциями,






предоставляемыми гипервизором. В качестве примера можно привести
паравиртуализованый Linux -- L4Linux. L4Linux представляет собой обычное ядро
Линукса, модифицированное таким образом, что оно работает с оборудованием
через абстракции L4. Изменения затрагивают лишь небольшую часть ядра.
Например, драйверы Linux не зависят от архитектуры. L4 представляет собой
просто еще одну архитектуру, на которую портирован Linux -- в его дереве
исходников появляется подкаталог l4 в каталоге arch.
То есть паравиртуализованная ОС -- это не ОС, запущенная в пробирке, как
Windows, запущенная под Virtual PC. Это вполне самостоятельная ОС, но для
возможности запуска нескольких ОС одновременно она запускается в очень
"тонкой" виртуальной машине, которая 1) абстрагирует оборудование от ОС
(подобно тому, как HAL в Windows NT абстрагирует железо от ядра Windows -- это
тоже разновидность виртуализации) 2) отдает часть оборудования одной ОС, и
часть -- другой.
Страница проекта исследований виртуализации L4Ka: [21]
Для исследований виртуализации проект Virtualization L4Ka использует микроядро
Pistachio в комбинации с менеджером ресурсов marzipan. Marzipan запускается как
root сервер и позволяет создавать системы взаимодействующих виртуальных
машин, разделяющих между собой ресурсы компьютера. Marzipan ведает
разделением ресурсов (память, устройства) между виртуальными машинами, а
также предоставляет средства для их взаимодействия. Также marzipan позволяет
одним виртуальным машинам "публиковать" сервисы, а другим -- находить эти
сервисы через посредство marzipan.
Marzipan является основой для проектов Drivers и Afterburner.
i) Проект Afterburner
Проект Afterburner автоматизирует создание паравиртуализированных версий
гостевых операционных систем. Это наиболее важно для тех ядер ОС, которые
больше не поддерживаются и не развиваются (например, ядро OS/2, ау, IBM'еры!).
Afterburner позволяет достичь нейтральности (независимости) как по отношению к
гипервизору, так и по отношению к гостевой ОС. Он позволяет создавать
"virtualization-friendly" ядра, которые могут работать без изменений на разных
гипервизорах, на данный момент это: L4, Xen v.2, Xen v.3, а также на голом железе.
Для этого используется монитор ресурсов marzipan, а также специальный модуль
afterburn-wedge. Wedge зависит от гипервизора и для каждого гипервизора он свой.
Проект Afterburner быстро развивается. Год назад я скачивал и собирал исходники
паравиртуализованного Linux'а, основанного на Afterburner. Тогда мне пришлось
применить патчи к исходникам Linux, Xen и binutils (из binutils afterburner
использует ассемблер as). При этом ассемблер был запатчен так, что он при
компиляции ядра ОС создавал специальный код, где "virtualization-sensitive"
инструкции заменялись на особый код, где вставлялись вызовы wedge. С тех пор
прошел год и многое изменилось. Я пока не пробовал новые версии afterburner, а из
главной страницы [22] трудно понять, как сейчас обстоит дело (на странице
написано очень двусмысленно и поверхностно, и я до конца так и не понял, как же
оно на самом деле работает; надо будет еще раз скачать исходники и
посмотреть...). Насколько я понял, дело движется к тому, что в будущем возможно
применение этого проекта к бинарникам ядра (!??). Как я понял, "virtualizationsensitive" инструкции патчатся так, что место вокруг этих инструкций забивается
инструкциями NOP, оставляя место для последующей замены их другими
инструкциями во время выполнения (?) (The Afterburner automatically locates
virtualization-sensitive instructions, pads them with scratch space for runtime instruction
rewriting, and annotates them.) То есть (как я понял), возможно автоматическое
патчение бинарника ядра ОС, и в результате получается ОС, без изменений







работающая на Xen, L4/marzipan и на голом железе!. Если это так, то этот проект
очень важен для OS/2. Это позволит нам, не имея исходников ядра, запускать его
на различных гипервизорах, на данный момент -- Xen и L4/marzipan. (хотя, не
помешает ли тут то, что многие OS/2-программы содержат 16-битные
фрагменты?... )
На Afterburner также основывается своя паравиртуализованная версия Linux от Uni.
Karlsruhe. (Кроме нее есть еще две версии L4Linux). По сравнению с исходным
линуксом, изменения затрагивают только ядро. Приложения обычного линукса не
требуют перекомпиляции и без изменений работают на L4Linux. L4Linux -- это
только пример паравиртуализованной ОС, "подопытный кролик" для
экспериментов в этой области.
ii) Проект Drivers
Проект Drivers [23] позволяет ОС, запущенным в виртуальных машинах на основе
L4 и marzipan, использовать драйвера устройств друг друга. ОС, в которой
запускаются драйвера назовем Driver OS, а ОС, использующая драйвера первой ОС
-- Client OS. Внутри Driver OS запускается приложение-маппер, транслирующее
запросы от Client OS-ов в формат запросов к ядру Driver OS. Также этот маппер
позволяет "мультиплексировать" драйвера Driver OS между несколькими ОСклиентами. Более того, путем запуска нескольких копий Driver OS, в каждой из
которых запускается определенный драйвер, можно изолировать разные драйверы
в разных виртуальных машинах. То есть, например, драйвер диска запускается в
одной VM, а драйвер сетевой карты -- в другой VM. Если первый драйвер упадет,
его можно рестартовать вместе с его виртуальной машиной. При этом, падение
одной виртуальной машины не затрагивает вторую VM, то есть драйвера 1)
изолированы друг от друга 2) их можно рестартовать. Драйвера запускаются в
своем неизменном виде. Кроме того, они запускаются в user level, так что падения
драйверов не затрагивают других операционных систем. Этот подход позволяет
использовать немодифицированные драйвера legacy-операционных систем. Пока
паравиртуализованные версии, для случая широкоиспользуемых ОС, имеет лишь
линукс. То есть, этот проект дает возможность использовать прежде всего,
драйвера Linux. Возможно создание паравиртуализированной ReactOS, и тогда
можно было бы использовать немодифицированные драйвера Windows. (Также
возможно, что и Microsоft повернется к нам лицом и снизойдет до обработки
Windows при помощи Afterburner -- все возможно, открыли же они, например,
исходники WindowsCE...). Если удастся Afterburner применить к OS/2, то возможно
также использование неизменных драйверов OS/2 путем запуска в виртуальной
машине современного ядра OS/2 одновременно с новым, основанным на микроядре
(хотя, не является ли тут препятствием их 16-битность?...).
2) Разработки NICTA
а) Kenge/Iguana/Wombat
Kenge -- это набор библиотек и инструментов для разработки. В том числе, для
разработки драйверов, работы с ком-портом, консолью и т. п. Реализация очередей,
семафоров, работа с таймером, форматами исполняемых файлов и прочее.
Инструменты включают свой IDL-компилятор Magpie, а также build environment,
основанный на scons. Scons -- это очень удобная и оригинальная утилита
автоматизации сборки, подобная make, которая зависимости между исходниками
строит на специальном объектно-ориентированном языке. ("объектноориентированные мейкфайлы"). Написана scons на языке python.
Kenge содержит уже готовый набор userlevel сервисов, составляющих
минимальную OS Personality, необходимую для реализации минимальной
инфраструктуры: Name server, root server, сервер, реализующий поддержку
последовательного порта. Эта минимальная OS Personality нацелена прежде всего









на встраиваемые применения, содержит минимальную инфраструктуру для
управления памятью и защиты. Имеет малую нагрузку на кеш (small cache
footprint). Также, позволяет работать на системах без поддержки виртуальной
памяти, что часто требуется во встраиваемых приложениях. Также имеется своя
подсистема драйверов. Этот набор userlevel сервисов называется Iguana Embedded
OS Personality.
На основе сервисов Iguana реализован также высокомобильный Linux server под
названием Wombat.
б) L4/Darwin aka Darbat
По аналогии с Wombat (паравиртуализованный Linux) существует проект под
названием Darbat, или L4/Darwin. Это ни что иное как порт ядра Darwin, на
котором основана MacOS X, на микроядро L4. Darbat пытается улучшить
производительность Darwin за счет использования IPC L4, которое намного более
производительное, чем IPC микроядра Mach, на котором основан Darwin. Также
Darbat содержит порт IOKit на L4, который стремится получить выгоду от
использования user-level драйверов (в Darwin многие драйвера работают в режиме
ядра, а в Darbat они выносятся в userlevel). Одной из целей является поддержка
немодифицированных драйверов Darwin в userspace. Darbat не стремится
полностью удалить Mach из Darwin, а взамен этого получить версию MacOS X,
почти без изменений работающую под L4, и использующую выгоды, которые дает
L4 по сравнению с Mach. Проводятся эксперименты по параллельному Запуску
Darbat и Wombat, а также их взаимодействию.
Darbat -- в первую очередь, надежда для макинтошников. Но и для нас было бы
достаточно заманчивым исполнять приложения MacOS X на одном десктопе с
нашей OS. Это еще один параллельный API, вдобавок в Linux и (возможно в
будущем) ReactOS.
Разработки NICTA на основе Pistachio выпускаются на основе BSD-лицензии, так
же как и само ядро Pistachio.
3) Разработки TU Dresden
TU Dresden на основе своего микроядра Fiasco разрабатывает ОС DROPS под
GNU-лицензией. DROPS содержит большой набор библиотек и userlevel сервисов
под названием L4Env (L4 Environment). L4Env также содержит средства
разработки, например, IDL-компилятор DICE.
L4Env содержит следующие сервисы: 1) консоль, поддержка виртуальных
консолей 2) сервер логов. Позволяет собирать в одном месте отладочные
сообщения от различных сервисов. В сочетании с libc и службой имен l4vfs
реализует поддержку stderr/stdout для неинтерактивных сервисов. 3) l4vfs -иерархический Name server, который интегрирует в одно дерево службы, файлы,
терминалы и позволяет реализовать в libc файловые функции типа open(), read(),
write() через специальные бэкенды. Поддерживаются две реализации libc -- порты
dietLibc и uCLibc. 4) поддержка простейшей работы с файлами без использования
файловой системы, например, получение файлов с tftp-сервера или с файловой
системы L4Linux. 5) Поддержка запуска исполняемых файлов формата ELF. 6)
Управление памятью. Реализуются свои примитивы работы с памятью поверх
примитивов микроядра: концепция Dataspaces и dataspace managers. 7) поддержка
примитивов синхронизации, работа с таймерами, семафорами. 8) Менеджер задач
9) доступ к оборудованию 10) Подсистема драйверов DDE (Device Driver
Environment)
DDE включает в себя поддержку драйверов Linux (DDE/Linux) и FreeBSD
(DDE/FreeBSD). Эта поддержка реализует подход, альтернативный подходу в L4Ka
Drivers. Драйвера погружаются в специальный слой, эмулирующий окружение
ядра Linux (а не запускает реальное ядро Linux).










Все это может быть полезно для реализации своих userlevel сервисов (прежде всего
Personality-neutral сервисы, не завязанные ни на какую ОС), а также поддержки
оборудования.
Также, идея реализации нескольких GUI на одном десктопе содержится в проекте
Nitpicker в рамках разработки DROPS. Nitpicker -- это идея GUI минимальной
сложности, реализующего минимальные примитивы для рисования окон. Nitpicker
сделан так, что различные оконные системы (например, родной оконный менеджер
DoPE системы DROPS, а также X Window из L4Linux) могут являться клиентами
Nitpicker. Nitpicker работает на более низком уровне, чем GUI, рисующие окна.
Примитивами для рисования являются buffers и views. Buffer -- это область
шаренной памяти, содержащая 2-мерные графические данные. Область памяти
выдается Nitpicker'у клиентом через разделяемую память. Вместо понятия окна
Nitpicker содержит более простое понятие, которое называется view. View-это
прямоугольная область на экране, содержащаяся внутри буфера. Каждый view
имеет определенный размер и положение на экране, определяемое клиентом. Views
могут перекрывать другие view в том же буфере. То есть, views внутри буфера,
предоставляемого каждым клиентом, могут иметь определенный Z-order (т.е., кто
над кем находится -- расположение по 3-ей оси координат). То есть, каждый клиент
nitpicker рисует внутри своего буфера, а не непосредственно на экране. Nitpicker
собирает воедино все буферы и рисует все views, в них содержащиеся, на экране,
собирая все в одну картинку. Кроме того, Nitpicker пытается изолировать клиенты
друг от друга, следя за безопасностью работы, что позволяет затруднить работу
различных key loggers и прочих троянов, записывающих нажатия клавиатуры и
делающих снимки экрана. Подробнее про это см. на сайте DROPS demo CD [18].
Здесь для нас ценной является сама идея сочетания различных оконных систем в
одном десктопе. Реально попробовать это в работе и поиграться с DoPE и
XWindow на одном десктопе можно, загрузив DROPS Demo CD [18].
4) Прочие разработки
a) SawMill Linux
Разработчики: IBM Watson research center, основан на L4/x86 (aka Lime Pip). Проект
больше не развивается, развитие закончено в 2001 году. Проект направлен на
разработку Linux personality, построенной на мультисерверной основе. То есть,
цель -- создать модульный, мультисерверный, а не монолитный Linux, использовав
преимущества микроядра. Что этот проект дает: лучшая Linux personality, чем
L4Linux. Минусы: проект не развивается. [26]
б) L4Minix
Порт Minix на L4Ka::Hazelnut. Разработчик: National Institute of Informatics
(Япония). Развивается с 2001 года, последнее обновление было в 2002 году. Проект
похоже, больше не развивается. Что проект дает: еще одна OS Personality.
4. Идеи на будущее
Создать реализацию OS/2 API вместе с возможностью работы параллельных API
других операционных систем, прежде всего -- Linux и Windows (на основе ReactOS
и L4Linux). Как OS/2 API, так и API других ОС реализуются как параллельные
personalities.
Разграничение различных personalities и раздача им ресурсов компьютера
реализуется на основе marzipan resource monitor. На основе Marzipan реализуется
менеджер аппаратных ресурсов (HRM) и root server, запускающий personality
neutral (PN) сервисы. В PN сервисы входят независимые от конкретной ОС
службы:
1) console server -- драйвер консоли, независимый от ОС
2) сервер логов -- сбор отладочных сообщений от всех серверов различных
personalities












3) Иерархический сервер имен
4) поддержка устройств при помощи подсистем драйверов
5) Поддержка драйверов файловых систем (IFS)
6) Поддержка драйверов исполняемых форматов IIF (Installable Image format),
наподобие IFS
Подсистемы драйверов входят в PN сервисы. Общий менеджер поддержки
оборудования, в который подключаются подсистемы драйверов. "Родная"
подсистема драйверов, входящая в PN сервисы. К "родной" подсистеме
добавляются driver frameworks, реализованные внутри OS Personalities, прежде
всего L4Linux и ReactOS. Общая схема примерно такова: Конкретная OS personality
либо реализует подсистему драйверов внутри себя, как L4Linux, либо (что более
желательно) обращается с запросами к менеджеру поддержки оборудования.
Менеджер оборудования перенаправляет запрос либо нативному драйверу
конкретного устройства (в "родной" поддержке оборудования), либо мапперу
внутри Driver OS (используется идея из проекта Drivers L4Ka). Таким образом, есть
как native drivers, которые предпочтительно использовать, либо, для подстраховки
на случай отсутствия native драйверов -- возможность использования драйверов
внутри OS personalities, прежде всего, L4linux.
OS/2 Personality реализуется на базе примитивов, реализованных в PN services. То
есть, API OS/2 -- более высокоуровневый. OS/2 API server реализует семантику
файловой системы OS/2 (буквы дисков, доступ к драйверам устройств через
файловую систему -- "файлы" в каталоге \DEV\, пайпы \PIPE\, и проч.) на основе
менеджера файловых систем, содержащегося в PN сервисах. Также, реализуется
VIO/KBD/MOU на основе примитивов, предоставляемых PN сервисами (например,
реализация VIO поверх консоли, предоставляемой console server.)
Идея построения системы, основанной на PN-сервисах, заимствована из OS/2
PowerPC. (См. [19])
Универсальный эмулятор x86, набазе которого строятся 1) исполнение 16-бит
инструкций в LX-файлах 2) реализуется эмуляция DOS, возможно, на базе
FreeDOS. (Прототип: MVM Personality из OS/2 PPC)
Единый десктоп для всех personalities. Предлагается использовать идею из
Nitpicker для интеграции разных оконных систем в один десктоп. То есть, PM и
XWindow работают через примитивы, предоставляемые аналогом Nitpicker.
5. Механизмы и API L4
Здесь я очень кратко (подробно не получится -- это выходит за рамки статьи)
расскажу об идеях, на основе которых реализовано L4. Подробнее см. в [11], [12],
[13], [3], [4]. Прошу прошения за неточности, если такие встретятся. ("Я не
волшебник, я еще только учусь" (c) ;)).
1) Основные понятия и абстракции
Микроядро реализует всего три абстракции (остальное реализуется в userlevel на их
базе):
i) Тред -- исполняемая и диспетчеризуемая единица. Имеет свой контекст -состояние регистров процессора.
ii) Адресное пространство -- Область виртуальной памяти, в которой исполняется
несколько тредов
iii) IPC (InterProcess Communication) -- средство взаимодействия между тредами.
Под задачей (task) понимается адресное пространство с исполняемыми в нем
тредами.
Также, к одним из основных механизмов микроядра относится планирование
процессов (scheduling). Микроядро содержит базу для реализации scheduling.
2) Треды











Треды идентифицируются числами -- Thread Id; дабы не плодить сущностей,
адресное пространство идентифицируется по номеру любого принадлежащего ему
треда.
Thread ID'ы могут идентифицировать обычные треды, виртуальные Interrupt треды,
а также есть специальные константы типа NilThread (идентифицирует "никакой"
тред), AnyThread (идентифицирует любой тред), они служат для задания значений
ThreadId в API-функциях, например, в операциях IPC. Виртуальные Interrupt треды
применяются для виртуализации обработки прерываний (см. ниже).
Тред называется локальным, если он принадлежит этому же адресному
пространству. Локальные треды адресуются специальными значениями ThreadID -значение ThreadID имеет особую маску битов.
Треды могут взаимодействовать через IPC. Операция IPC передает сообщение от
треда к треду. При этом посылающий и получающий сообщение треды в этой
операции идентифицируются по Thread ID'ам.
Тред оперирует памятью и регистрами. Память может быть физической и
виртуальной. Виртуальная память поделена на независимые адресные
пространства. (Про конструирование адресных пространств см. ниже в разделе
"управление памятью").
Каждый тред имеет свой контекст -- регистры IP, SP, FLAGS, TCRs (Thread Control
Registers, см. ниже). Также, каждый тред имеет ассоциированные с ним пейджер,
шедулер, а также exception handler. Контекст треда сохраняется в ядре в области,
называемой TCB (Thread Control Block), причем часть TCB сохраняется в
специальной области UTCB (User mode TCB), содержащейся в адресном
пространстве самогО треда -- она открыта для доступа из usermode.
3) Управление памятью (flexpages, адресные пространства и их рекурсивное
конструирование)
Адресное пространство состоит из страниц памяти. Интересно, что L4 оперирует
виртуальными страницами, независимыми от архитектуры -- они называются
flexpages. Flexpages имеют размер, больший или равный аппаратной страницы
памяти процессора, и кратный степени двойки. Сама страница также должна быть
выровнена по своему размеру и сам размер должен быть не меньше 1 К. Flexpages
рассматриваются как неделимые объекты.
Базовое "плоское" адресное пространство, отображенное идемпотентно (то есть,
один в один) на физическую память, называется sigma0, как и одноименный сервер.
Страницы памяти (flexpages) могут отображаться из одного адресного
пространства в другое. После такой операции, называемой mapping, страница
памяти становится доступной в обеих адресных пространствах. Так реализуется
разделяемая память. Кроме операции mapping есть еще операция передачи
страницы памяти (granting). Она отличается от предыдущей тем, что адресное
пространство A, предоставляющее страницу памяти адресному пространству B,
теряет доступ к этой странице. То есть, страница передается насовсем. Эта
операция, в отличие от предыдущей, необратима.
Отображение (mapping) или передача (granting) страницы памяти осуществляется
путем посылки специального IPC-сообщения, в котором закодирован набор
flexpages (MapItems и GrantItems). Ядро перехватывает посылку такого сообщения
и при этом реализует операцию map/grant. То есть, операция map/grant
осуществляется как побочный эффект передачи специального сообщения, а не при
помощи API-функции. Напротив, для обратной операции unmap предназначен
специальный системный вызов Unmap(). Операция Map (как и Grant) реализована
таким образом, что процесс-получатель имеет возможность указать окно,
ограничивающее область, в которую необходимо отобразить flexpages.











Операции mapping, granting и unmapping реализуются динамически, то есть, во
время выполнения. Они основаны на операциях с таблицами страниц процессора,
которые осуществляются динамически по запросу программ.
Адресные пространства конструируются рекурсивно. Иначе говоря, есть исходное
адресное пространство sigma0. Задача sigma0 отдает области памяти серверам A и
B путем операции granting. A передает (через map или grant) части полученной
памяти серверам A1 и A2, B -- передает B1 и B2. Те -- передают дальше по
цепочке. Получается иерархическая система менеджеров памяти. В результате
адресные пространства могут конструироваться произвольным образом из
исходного плоского адресного пространства (sigma0), и на этом основано
управление памятью. Все эти операции доступны обычным непривилегированным
userlevel программам. То есть, управление памяти реализуется в userlevel.
Виртуальная память, подкачка с диска и обработка page faults (страничных отказов)
производится при помощи userlevel серверов, называемых пейджерами (pagers).
Каждый тред имеет ассоциированный с ним пейджер. Когда тред обращается к
странице памяти, которая еще не отображена в его адресное пространство,
возникает page fault (иначе говоря, исключение процессора TRAP 000e).
Обработчик page fault'а в ядре перехватывает управление и при этом посылает
специальное IPC-сообщение пейджеру треда. Это сообщение отправляется ядром
от имени сбойнувшего треда (это называется "обманывающее IPC" -- "deceiving
IPC" а сам тред называется virtual sender). Пейджер реализует какую-то логику
обработки page fault'ов и может решить отобразить flexpages в адресное
пространство сбойнувшего треда. Это, как мы уже говорили, также реализуется
через IPC. -- Пейджер просто отвечает на сообщение о page fault'е сообщением с
отображаемыми flexpages.
Пейджеры могут обращаться к менеджерам памяти, а также часто бывает, что обе
роли совмещены в одной программе.
4) IPC и язык IDL (использование методов распределенных систем)
Базовым методом межпроцессного взаимодействия является механизм передачи
сообщений, реализованный в ядре. Также важным механизмом IPC является
разделяемая память. Но собственно аббревиатура IPC обычно подразумевает
именно передачу сообщений.
Передача сообщений является синхронной и не буферизованной (synchronous and
unbuffered). Т.е., посылающий тред блокируется, пока получающий не войдет в
фазу receive и не получит сообщение. -- Системный вызов IPC() объединяет две
фазы -- send и receive. обе из которых опциональны (определяется параметрами
вызова IPC()). Один из тредов должен находиться в фазе send, другой в фазе
receive. Получающий тред должен предоставить буферы для сообщения; в ядре
сообщение не буферизуется.
Синхронность и не буферизованность IPC является одной из причин высокой
производительности IPC в L4. Напротив, в микроядре Mach IPC было асинхронным
и буферизованным (IBM-овское микроядро, основанное на Mach, на базе которого
была построена OS/2 PPC, содержало улучшения. IPC в нем было изменено на
синхронное, что дало повышение производительности [19]).
Также следует отметить, что сообщения в L4 не проверяются на правильность, в
отличие от Mach.
Также, как мы уже упоминали, в L4 отсутствует понятие порта, как в Mach, что
упрощает IPC и дает прирост производительности.
Операции IPC могут осуществляться вручную, но здесь для программиста очень
много рутинной работы. Поэтому для автоматизации этих операций служат
генераторы интерфейсов. Генераторы интерфейсов используют методы
распределенных систем -- язык IDL (Interface Definition Language). Использование









IDL можно встретить в OS/2 Warp Toolkit, если вы программируете SOMприложения. Использование языка IDL неслучайно. Как и в распределенных
системах (Corba/DSOM, COM, DCE), микроядерная система состоит из множества
объектов (серверов), взаимодействующих между собой при помощи протоколов,
передающих сообщения через жестко заданные интерфейсы. И во всех этих
случаях есть:
1) Фаза сборки сообщения и его посылки на стороне клиента, а также получение и
разборка ответов сервера и их обработка.
2) На стороне сервера есть цикл ожидания, разборки и обработки сообщений от
клиентов.
Обе эти фазы автоматизируются IDL-компилятором (IDL Compiler, Interface
Generator). Для этого внешние интерфейсы сервера кодируются на языке IDL. IDLкомпилятор обрабатывает исходник на языке IDL и по нему строит:
1) client-side stub
2) server loop
Все это делается автоматически и на выходе компилятора IDL получаются файлы
на языках C, C++, Ada и проч.
Для случая языка C на выходе IDL-компилятора получается 3 файла:
1) client-side stub
2) server loop
3) хедер, включаемый в вашу программу
Для микроядра L4 существует несколько разных IDL-компиляторов, на данный
момент известны такие компиляторы как, IDL4, DICE, Magpie а также Flick. Они
генерируют высокопроизводительные и оптимизированные stub-ы,
производительность которых сравнима с производительностью при ручной
оптимизации. [16]
5) Виртуальные регистры
Кроме памяти, треды имеют дело также с регистрами. L4 реализует виртуальные
регистры, независимые от архитектуры. В зависимости от конкретного типа
процессора, виртуальные регистры могут отображаться как на реальные регистры
процессора, так и на области памяти. Или же часть из них отображается на память,
а часть -- на регистры процессора.
Существует 3 класса виртуальных регистров:
a) TCRs (Thread Control Registers) -- служат для хранения контекста треда
б) MRs (Message Registers) -- служат для хранения IPC-сообщений в операции
передачи/приема
в) BRs (Buffer Registers) -- служат для хранения буферов при передаче строк
6) API
API L4 содержит очень небольшое количество функций. В оригинальной версии
ядра их было всего 7. Для API версии X.2 (L4Ka::Pistachio) имеется 11 системных
вызовов. Системные вызовы делятся на обычные и привилегированные.
Привилегированные могут вызываться только привилегированными тредами (т.е.,
тредами, исполняющимися в адресном пространстве roottask)
Вот что они собой представляют:
позволяет получить адрес таблицы KIP
ii) ExchangeRegisters() заменяет или возвращает состояние регистров треда
- служит для добавления или удаления тредов в адресное
iii) ThreadControl()
- пространство (привилегированный системный вызов)
i)
KernelInterface()
- получает системное время. Обычно не требует перехода в kernel
- mode (это удивительно, но так написано в документации!).
- используется шедулерами для задания значения кванта времени,
v) Schedule()
- приоритета и других параметров
- вызывающий тред освобождает процессор и дает возможность
vi) ThreadSwitch()
- передачи управления другому треду
- выполняет операцию unmap для указанных flexpages
vii) Unmap()
- (виртуальных страниц памяти)
- управляет адресными пространствами (привилегированный
viii) SpaceControl()
- системный вызов)
выполняет операцию приема/передачи сообщения. Существует
в двух версиях: просто IPC и LIPC -- Lightweight IPC -ix) IPC()
специальная версия этого системного вызова, оптимизированная
для передачи между тредами, исполняющимися в одном и том
же адресном пространстве. В остальном обе версии идентичны.
управляет параметрами процессора(-ов). Может менять
x) ProcessorControl()
внешнюю и внутреннюю частоту процессора и его вольтаж
(привилегированный системный вызов)
- управляет атрибутами страниц памяти (привилегированный
xi) MemoryControl()
- системный вызов).
iv) SystemClock()







Каждая из этих функций объединяет множество вариантов их использования.
7) Механизмы безопасности
Одним из методов разграничения различных подсистем и OS Personalities является
механизм Кланов и Шефов (Clans and Chiefs). Если задача A создала задачи B, C и
D, то сама задача A становится их шефом, а сами задачи B, C и D образуют клан.
Каждая задача может создать свой клан, для которого она будет являться шефом.
На кланах и шефах основывается разграничение подсистем -- задача B может слать
сообщения только членам своего клана, либо своему шефу. Если B попытается
послать сообщение задаче, не входящей в ее клан, то оно (сообщение)
принудительно направляется шефу. Шеф может как "дропнуть" сообщение, так и
перенаправить его шефу другого клана (а он уже -- членам своего клана). Кланы
могут быть вложенными. Этот механизм разграничивает разные подсистемы и ОСы путем перенаправления потока сообщений IPC.
Также, вторым механизмом обеспечения безопасности является принцип: серверы
(например, roottask и sigma0) предоставляют ресурсы первому запросившему
клиенту (например, sigma0 отдает память первому запросившему серверуменеджеру памяти), осталь- ным они отказывают в доступе. Так как первыми
ресурсы запрашивают начальные серверы, список которых определяет системный
администратор или разработчик дистрибутива ОС, то кто угодно не может
запросить ресурс и завладеть им.
Также, различные стратегии доступа к оборудованию, портам и памяти могут быть
реализованы через user-space пейджеры и менеджеры памяти.
8) Работа с оборудованием и драйверы в userlevel
Для случая микроядра драйвер -- это обычная userlevel программа, исполняющаяся
в ring3. Естественно, драйвер должен получить ресурсы -- IRQ, на которые он
вешается как обработчик прерывания и порты либо память, отображенную на
устройство. Получает он эти ресурсы от специального сервера-менеджера
ресурсов. (А сам этот менеджер ресурсов получает их у микроядра и sigma0 на
правах первого запрашивающего сервера). Уже реализованы специальные





менеджеры аппаратных ресурсов, и существует более-менее общепринятый
интерфейс к таким менеджерам. Например, в l4env роль такого менеджера
ресурсов выполняет сервер l4io; сам общепринятый интерфейс называется omega0.
Omega0 также реализует интерфейс к контроллеру прерываний (например, посылка
сигнала EOI) и работу с PCI configuration space и т. п.
a) обработка прерываний
Если приходят прерывания от устройства, ядро перехватывает их, и при этом
направляет IPC-сообщение треду-обработчику прерывания. Причем, это сообщение
приходит от имени несуществующего (виртуального) треда с особым значением
Thread ID -- Interrupt Thread. Таким образом реализована обработка прерываний в
user mode -- сигналы прерывания виртуализуются через посылку сообщений IPC,
приходящих от виртуальных тредов.
б) работа с портами и memory-mapped i/o.
На большинстве архитектур регистры устройств отображаются в обычную
физическую память. Поэтому сервер может запросить такую память в виде
обычных flexpages у менеджера памяти, например, sigma0. На платформе PC
существует отдельное адресное пространство портов ввода-вывода. В этом случае
для этого адресного пространства также можно выполнять операции map/grant и
unmap. Для этого служат специальные i/o flexpages. То есть, серверы (драйверы)
могут запрашивать стандартным образом доступ к портам у менеджера памяти,
управляющего портами, через операции map/grant. Гранулярность i/o flexpages
составляет 1 байт.
Для случая доступа к i/o портам также возможно возникновение page fault'ов при
доступе к неотображенной области адресного пространства портов. Обрабатывает
такие page fault'ы также пейджер, ассоциированный с тредом драйвера устройства.
Этот пейджер должен следовать специальному протоколу.


6. Общая структура, из чего состоит минимальная L4 система


7. Инициализация системы
Минимальная система состоит из собственно микроядра, загрузчика kickstart,
корневого менеджера памяти sigma0 и корневого сервера (rootserver). Только
микроядро исполняется на высшем уровне привилегий. roottask и sigma0
исполняются в userlevel. Roottask -- базовый сервер, отвечающий за
инициализацию системы, а также за выполнение привилегированных операций.
Sigma0 -- начальный менеджер памяти, который владеет всей физической памятью
системы. Sigma0 может отдавать страницы физической памяти другим серверам,
реализуя для этого свой простейший протокол взаимодействия.
Для загрузки системы, основанной на L4, традиционно используется загрузчик
GRUB и стандарт Multiboot. При этом GRUB загружает программу kickstart -- спец.
дополнительный загрузчик, выступающий в роли multiboot-ядра, и набор
дополнительных модулей. Первым модулем должно быть ядро L4, вторым -sigma0, третьим -- roottask, и далее следуют добавочные модули. Kickstart грузит
L4, sigma0 и rootserver из их образов в памяти, полученных от GRUB'а, делает
fixups, заполняет поля в области под названием Kernel Interface Page (KIP). KIP
находится внутри образа микроядра L4 в памяти. Она очень важна для системы и
содержит адреса начальных серверов, адреса точек входа системных вызовов
микроядра, таблицы дескрипторов областей памяти и дополнительных модулей,
загруженных GRUB'ом, а также прочую информацию (все эти поля заполняет
kickstart и передает ядру). Затем kickstart запускает микроядро. Микроядро стартует
начальные серверы -- sigma0 и roottask. Roottask после этого инициализирует все
userlevel сервисы системы, в том числе, различные personalities. Дополнительные
модули, загруженные GRUB'ом, тоже могут стартоваться roottask'ом, причем
ссылка на таблицу с адресами этих модулей находится в KIP, откуда Roottask и

получает информацию о их местонахождении. Менеджеры памяти при
инициализации системы получают всю память от sigma0.
Для создания более подходящего, чем GRUB, загрузчика, использующего
характерные для OS/2 механизмы загрузки, например, использование microfsd,
проектом osFree решено было совместить механизмы microfsd с логикой загрузки,
использующей стандарт multiboot. Наш загрузчик называется FreeLdr, он находится
в процессе разработки. Загрузка L4 уже почти реализована.
Ядро́ — центральная часть операционной системы, обеспечивающая
приложениям координированный доступ к ресурсам компьютера, таким как
процессорное время, оперативная память, внешнее оборудование. Обычно
предоставляет сервисы файловой системы.
Как основопологающий элемент ОС, ядро представляет собой наиболее
низкий уровень абстракции для доступа приложений к ресурсам системы,
необходимым для его работы. Как правило, ядро предоставляет такой доступ
исполняемым процессам соотвествующих приложений за счет использования
механизмов межпроцессного взаимодействия и обращения приложений к
системным вызовам ОС.
Описанная задача может различаться в зависимости от типа архитектуры ядра
и способа ее реализации.
Содержание
[убрать]
1 Типы архитектур ядер операционных
систем
1.1 Монолитное ядро
1.2 Модульное ядро
1.3 Микроядро
1.4 Экзоядро
1.5 Наноядро
1.6 Гибридное ядро
2 Ссылки
2.1 Литература
Типы архитектур ядер
операционных систем
[править]
[править]
Монолитное ядро
Основная статья: Монолитное ядро
Монолитное ядро предоставляет богатый набор абстракций
оборудования. Все части монолитного ядра работают в одном адресном
пространстве.
Старые монолитные ядра требовали перекомпиляции при любом
изменении состава оборудования. Большинство современных ядер
позволяют во время работы подгружать модули, выполняющие части
функции ядра.
Достоинства: Скорость работы, упрощённая разработка модулей.
Недостатки: Поскольку всё ядро работает в одном адресном пространстве,
сбой в одном из компонентов может нарушить работоспособность всей
системы.
В этом случае компоненты операционной системы являются не
самостоятельными модулями, а составными частями одной большой
программы. Такая структура операционной системы называется
монолитным ядром (monolithic kernel). Монолитное ядро представляет
собой набор процедур, каждая из которых может вызвать каждую. Все
процедуры работают в привилегированном режиме.
Таким образом, монолитное ядро — это такая схема операционной
системы, при которой все ее компоненты являются составными частями
одной программы, используют общие структуры данных и
взаимодействуют друг с другом путем непосредственного вызова
процедур. Для монолитной операционной системы ядро совпадает со всей
системой.
Во многих операционных системах с монолитным ядром сборка ядра, то
есть его компиляция, осуществляется отдельно для каждого компьютера,
на который устанавливается операционная система. При этом можно
выбрать список оборудования и программных протоколов, поддержка
которых будет включена в ядро. Так как ядро является единой
программой, перекомпиляция — это единственный способ добавить в него
новые компоненты или исключить неиспользуемые. Следует отметить, что
присутствие в ядре лишних компонентов крайне нежелательно, так как
ядро всегда полностью располагается в оперативной памяти. Кроме того,
исключение ненужных компонентов повышает надежность операционной
системы в целом.
Монолитное ядро — старейший способ организации операционных систем.
Примером систем с монолитным ядром является большинство Unixсистем.
В монолитном ядре выделяются вкрапления сервисных процедур,
соответствующих системным вызовам. Сервисные процедуры
выполняются в привилегированном режиме, тогда как пользовательские
программы — в непривилегированном. Для перехода с одного уровня
привилегий на другой иногда может использоваться главная сервисная
программа, определяющая, какой именно системный вызов был сделан,
корректность входных данных для этого вызова и передающая управление
соответствующей сервисной процедуре с переходом в привилегированный
режим работы.
Данный тип архитектуры ядер имеет преимущества. В частности,
монолитное ядро более производительно, чем микроядро, поскольку
состоит не из множества разрозненных процессов, «общающихся» между
собой через механизм посылки сообщений, а работает в одном адресном
пространстве, кроме того нет необходимости осуществлять переключения
между процессами-сервисами.
Примером монолитного ядра является Linux, имеющее, кроме того,
архитектуру модульного ядра. Оно оптимизировано для более высокой
производительности с минимальными контекстными переключениями.
Такая архитектура упрощает поддержку кода ядра для разработчиков, но
требует перекомпиляции ядра при добавлении новых устройств. Следует
отметить, что описанные здесь различия являются «классическими», на
практике монолитные ядра могут поддерживать модульность (что зачастую
и происходит), а микроядра могут требовать перекомпиляции.
Примеры: Традиционные ядра UNIX(такие как BSD), Linux; ядро MS-DOS.
[править]
Модульное ядро
Основная статья: Модульное ядро
Модульное ядро — современная, усовершенствованная
модификация архитектуры монолитных ядер операционных систем
компьютеров.
В отличие от «классических» монолитных ядер, считающихся ныне
устаревшими, модульные ядра, как правило, не требуют полной
перекомпиляции ядра при изменении состава аппаратного
обеспечения компьютера. Вместо этого модульные ядра
предоставляют тот или иной механизм подгрузки модулей ядра,
поддерживающих то или иное аппаратное обеспечение (например,
драйверов). При этом подгрузка модулей может быть как
динамической (выполняемой «на лету», без перезагрузки ОС, в
работающей системе), так и статической (выполняемой при
перезагрузке ОС после переконфигурирования системы на загрузку
тех или иных модулей).
Все модули ядра работают в адресном пространстве ядра и могут
пользоваться всеми функциями, предоставляемыми ядром. Поэтому
модульные ядра продолжают оставаться монолитными.
Модульные ядра удобнее для разработки, чем традиционные
монолитные ядра, не поддерживающие динамическую загрузку
модулей, так как от разработчика не требуется многократная полная
перекомпиляция ядра при работе над какой-либо его подсистемой или
драйвером. Выявление, локализация, отладка и устранение ошибок
при тестировании также облегчаются.
Модульные ядра предоставляют особый программный интерфейс
(API) для связывания модулей с ядром, для обеспечения
динамической подгрузки и выгрузки модулей. В свою очередь, не
любая программа может быть сделана модулем ядра: на модули ядра
накладываются определённые ограничения в части используемых
функций (например, они не могут пользоваться функциями
стандартной библиотеки С/С++ и должны использовать специальные
аналоги, являющиеся функциями API ядра). Кроме того, модули ядра
обязаны экспортировать определённые функции, нужные ядру для
правильного подключения и распознавания модуля, для его
корректной инициализации при загрузке и корректного завершения при
выгрузке, для регистрации модуля в таблице модулей ядра и для
обращения из ядра к сервисам, предоставляемым модулем.
Не все части ядра могут быть сделаны модулями. Некоторые части
ядра всегда обязаны присутствовать в оперативной памяти и должны
быть жёстко «вшиты» в ядро. Также не все модули допускают
динамическую подгрузку (без перезагрузки ОС). Степень модульности
ядер (количество и разнообразие кода, которое может быть вынесено
в отдельные модули ядра и допускает динамическую подгрузку)
различна в различных архитектурах модульных ядер. Ядро «Linux» в
настоящее время имеет более модульную архитектуру, чем ядра *BSD
(FreeBSD, NetBSD, OpenBSD).
Общей тенденцией развития современных модульных архитектур
является всё большая модуларизация кода (повышение степени
модульности ядер), улучшение механизмов динамической подгрузки и
выгрузки, уменьшение или устранение необходимости в ручной
подгрузке модулей или в переконфигурации ядра при изменениях
аппаратуры путём введения тех или иных механизмов
автоматического определения оборудования и автоматической
подгрузки нужных модулей, универсализация кода ядра и введение в
ядро абстрактных механизмов, предназначенных для совместного
использования многими модулями (примером может служить VFS —
«виртуальная файловая система», совместно используемая многими
модулями файловых систем в ядре Linux).
[править]
Микроядро
Основная статья: Микроядро
Микроядро предоставляет только элементарные функции
управления процессами и минимальный набор абстракций для
работы с оборудованием. Бо́льшая часть работы осуществляется
с помощью специальных пользовательских процессов,
называемых сервисами.
Достоинства: Устойчивость к сбоям оборудования, ошибкам в
компонентах системы.
Недостатки: Передача данных между процессами требует
накладных расходов.
Современная тенденция в разработке операционных систем
состоит в перенесении значительной части системного кода на
уровень пользователя и одновременной минимизации ядра. Речь
идет о подходе к построению ядра, называемом микроядерной
архитектурой (microkernel architecture) операционной системы,
когда большинство ее составляющих являются самостоятельными
программами. В этом случае взаимодействие между ними
обеспечивает специальный модуль ядра, называемый
микроядром. Микроядро работает в привилегированном режиме и
обеспечивает взаимодействие между программами, планирование
использования процессора, первичную обработку прерываний,
операции ввода-вывода и базовое управление памятью.
Остальные компоненты системы взаимодействуют друг с другом
путем передачи сообщений через микроядро.
Основное достоинство микроядерной архитектуры — высокая
степень модульности ядра операционной системы. Это
существенно упрощает добавление в него новых компонентов. В
микроядерной операционной системе можно, не прерывая ее
работы, загружать и выгружать новые драйверы, файловые
системы и т. д. Существенно упрощается процесс отладки
компонентов ядра, так как новая версия драйвера может
загружаться без перезапуска всей операционной системы.
Компоненты ядра операционной системы ничем принципиально не
отличаются от пользовательских программ, поэтому для их
отладки можно применять обычные средства. Микроядерная
архитектура повышает надежность системы, поскольку ошибка на
уровне непривилегированной программы менее опасна, чем отказ
на уровне режима ядра.
И чтобы добавить в ОС с микроядром драйвер того или иного
устройства, не надо перекомпилировать всё ядро, а надо лишь
отдельно откомпилировать этот драйвер и запустить его в
пользовательском пространстве.
В то же время микроядерная архитектура операционной системы
вносит дополнительные накладные расходы, связанные с
передачей сообщений, что отрицательно влияет на
производительность. Для того чтобы микроядерная операционная
система по скорости не уступала операционным системам на базе
монолитного ядра, требуется очень аккуратно проектировать
разбиение системы на компоненты, стараясь минимизировать
взаимодействие между ними. Таким образом, основная сложность
при создании микроядерных операционных систем —
необходимость очень аккуратного проектирования.
Микроядра типа ядра ОС Minix и GNU Hurd развиваются
медленно, гораздо медленнее, чем Linux и ядро систем семейства
BSD, но они обладают огромным потенциалом, то есть заделом на
будущее, и, возможно, в этом самом будущем, достигнут
аналогичного функционала.
Клаcсическим пpимером микpоядерной cистемы являeтся Symbian
OS. Этo пpимер pаспространенной и oтработанной микpоядеpной
(a нaчиная c вeрсии Symbian OS v8.1, и нaноядерной)
oперационной сиcтемы. B oтличии oт Windows NT, cоздателям
Symbian OS удaлось cовмеcтить эффeктивность и кoнцептуальную
cтройность, нeсмотря нa тo чтo совремeнные вeрcии этoй сиcтемы
пpедостaвляют обширные возможности, в тoм чиcле cредства для
pабoты c пoтоковыми дaнными, cтеками пpотoколов, кpитичными к
лaтентности ядpа, гpафикой и видеo выcокого pазрeшения).
Будyчи микpoядерной oпeрационной cистемой, Symbian «вынoсит»
пpaктически вcе пpикладные (т.e. выxoдящие зa прeделы
кoмпетeнции ядpа) зaдачи в мoдули-сeрверы, фyнкциoнирующие в
пoльзовательском aдреcном пpoстранствe.
Примеры: Symbian OS; Mach, используемый в GNU/Hurd и MacOS
X; QNX; AIX; Minix ; ChorusOS ; AmigaOS; MorphOS.
[править]
Экзоядро
Основная статья: Экзоядро
Экзоядро — ядро операционной системы компьютеров,
предоставляющее лишь функции для взаимодействия между
процессами и безопасного выделения и освобождения
ресурсов.
[править]
Наноядро
Основная статья: Наноядро
Наноядро — архитектура ядра операционной системы
компьютеров, в рамках которой крайне упрощённое и
минималистичное ядро выполняет лишь одну задачу —
обработку аппаратных прерываний, генерируемых
устройствами компьютера. После обработки прерываний
от аппаратуры наноядро, в свою очередь, посылает
информацию о результатах обработки (например,
полученные с клавиатуры символы) вышележащему
программному обеспечению при помощи того же
механизма прерываний. Примером является KeyKOS самая первая ОС на наноядре. Первая версия вышла ещё
в 1983-ем году.
[править]
Гибридное ядро
Основная статья: Гибридное ядро
Гибридные ядра это модифицированные микроядра,
позволяющие для ускорения работы запускать
«несущественные» части в пространстве ядра.
Имеют «гибридные» достоинства и недостатки.
Все рассмотренные подходы к построению
операционных систем имеют свои достоинства и
недостатки. В большинстве случаев современные
операционные системы используют различные
комбинации этих подходов. Так, например, ядро
«Linux» представляет собой монолитную систему с
элементами микроядерной архитектуры. При
компиляции ядра можно разрешить динамическую
загрузку и выгрузку очень многих компонентов ядра —
так называемых модулей. В момент загрузки модуля
его код загружается на уровне системы и связывается
с остальной частью ядра. Внутри модуля могут
использоваться любые экспортируемые ядром
функции.
Существуют варианты ОС GNU, в которых вместо
монолитного ядра применяется ядро Mach (такое же,
как в Hurd), а поверх него крутятся в
пользовательском пространстве те же самые
процессы, которые при использовании Linux были бы
частью ядра. Другим примером смешанного подхода
может служить возможность запуска операционной
системы с монолитным ядром под управлением
микроядра. Так устроены 4.4BSD и MkLinux,
основанные на микроядре Mach. Микроядро
обеспечивает управление виртуальной памятью и
работу низкоуровневых драйверов. Все остальные
функции, в том числе взаимодействие с прикладными
программами, осуществляется монолитным ядром.
Данный подход сформировался в результате попыток
использовать преимущества микроядерной
архитектуры, сохраняя по возможности хорошо
отлаженный код монолитного ядра.
Наиболее тесно элементы микроядерной архитектуры
и элементы монолитного ядра переплетены в ядре
Windows NT. Хотя Windows NT часто называют
микроядерной операционной системой, это не совсем
так. Микроядро NT слишком велико (более 1 Мбайт),
чтобы носить приставку «микро». Компоненты ядра
Windows NT располагаются в вытесняемой памяти и
взаимодействуют друг с другом путем передачи
сообщений, как и положено в микроядерных
операционных системах. В то же время все
компоненты ядра работают в одном адресном
пространстве и активно используют общие структуры
данных, что свойственно операционным системам с
монолитным ядром. По мнению специалистов
Microsoft, причина проста: чисто микроядерный дизайн
коммерчески невыгоден, поскольку неэффективен.
Таким образом, Windows NT можно с полным правом
назвать гибридной операционной системой.
Смешанное ядро, в принципе, должно объединять
преимущества монолитного ядра и микроядра:
казалось бы, микроядро и монолитное ядро —
крайности, а смешанное — золотая середина. В них
возможно добавлять драйвера устройств двумя
способами: и внутрь ядра, и в пользовательское
пространство. Но на практике концепция смешанного
ядра часто подчёркивает не только достоинства, но и
недостатки обоих типов ядер (тот же NT со
смешанным ядром не может видеть НЖМД большого
объёма в обход BIOS, в то время как GNU/Linux с его
монолитным ядром обеспечивает такую возможность,
поскольку возможность видеть НЖМД в обход BIOS
встроена в его ядро).