Шрифт:
Один из «косметических» вариантов решения проблемы был предложен Мэттом Диллоном и реализован им в системе DragonFlyBSD, о которой рассказывалось в предыдущей главе. Прошедшие с её появления годы доказали жизнеспособность этой реализации. Однако проблемы «большого» монолитного ядра это не снимало.
Для кардинального решения проблемы устойчивости ядра и были придуманы микроядра. Идея их – в том, чтобы, по словам Таненбаума, «вынести ядро за пределы ядра». То есть оставить в ядре только средства управления базовой аппаратурой, а драйверы устройств и сервисы выделить в отдельные программы, функционирующие в пользовательском пространстве памяти. При необходимости они обращаются к функциям ядра через специальные процедуры, но влиять на него каким-либо образом не могут. Такой подход приводит к повышению надежности системы, но снижает производительность, поскольку требует дополнительных накладных расходов.
Собственно, идея микроядра появилась очень давно, чуть ли не одновременно с самыми первыми UNIX'ами. Однако долгое время производительность машин не позволяла эффективно использовать микроядра в составе практически применяемых систем. Тем не менее, различных их реализаций было создано очень много. Время от времени то или иное микроядро пропагандировалось как основа операционной системы будущего, но удачных реализаций законченных микроядерных систем оказалось довольно мало.
Среди удачных решений на базе микроядра наибольшей известностью пользуется QNX. Правда, эта система лишь недавно начала то приоткрывать свой код, то закрывать его обратно, и потому об её устройстве известно немного. Да и как ОС общего назначения она никогда не позиционировалась.
Из свободных микроядерных реализаций наибольшую известность приобрело микроядро Mach, разрабатывавшееся вплоть до второй половины 90-х годов университетами – сначала Карнеги-Меллона, а затем штата Юта. Различные его версии в разное время составляли основу законченных систем, как свободных – BSD Mach (она же xMach) или Yamitt, так и проприетарных – NeXT и продолжившей её дело MacOS X. Все они имели в своем составе микроядро Mach, поверх которого запускалась драйверно-сервисная часть от ядра BSD, собранная в виде отдельного модуля.
Впрочем, из всех перечисленных систем только BSD Mach можно назвать по настоящему микроядерной, так как у него BSD-окружение ядра функционировало в пользовательском пространстве. И у NeXT, и у MacOS X BSD-окружение запускалось в том же пространстве ядра, так что микроядерными их можно назвать только по имени. А Yamitt в том виде, в каком я её наблюдал, просто не запускалась вообще.
Наконец, как мы видели, начиная с 1987 года и по настоящее время существует MINIX 1/2, основанная на собственной реализации микроядра. Каковую, в рамках очерченных для ннеё задач, можно считать удачной. А вот будет ли сопутствовать удача её потомку – микроядру нашей героини, MINIX 3, рассудит история.
Собственно о MINIX 3
Для начала заметим, что Таненбаум, по его же словам, не ставил самоцелью создание именно микроядерной ОС: задачей его команды было просто построение системы надежной и безопасной. Другое дело, что решение этой задачи им всегда виделось именно в микроядерной архитектуре. Почему он и предложил таковое, причем в виде, кардинально отличающемся от всех предлагавшихся ранее реализаций.
Отличие первое – микроядро MINIX 3 самое микроядреное микроядро в мире. Из него вычищено все, кроме перечисленных ранее компонентов, таких, как обработчик прерываний, средства запуска и останова процессов, планировщик задач, механизм межпроцессного взаимодействия; правда, почему-то в ядро включён и один из сервисов – сервис часов. В результате все это хозяйство укладывается менее чем в 4000 строк кода – и только оно исполняется в пространстве ядра.
Второе отличие – драйверная и сервисная части, вычлененные из ядра, разделены между собой. В результате образуется знаменитая четырехслойная модель – метафора, в основании которой лежит ядро, надстраиваемое «драйверным слоем», которое, в свою очередь, перекрывается «сервисным слоем» и венчается «слоем пользовательских программ».
Кроме того – и это третье отличие, – каждый драйвер и каждый сервис представляет собой отдельный процесс в пользовательском пространстве, аналогично обычным пользовательским приложениям. В результате ни один драйвер и ни один сервис, как бы криво они не были написаны, не в состоянии обрушить всю систему – точно также, как в любом UNIX'е это (почти) никогда не могут сделать обычные пользовательские приложения. Не могут повлиять они и на соседние процессы, так как напрямую взаимодействовать они не могут, а вынуждены при необходимости обращаться к ядру.
Наконец, четвертое, и, пожалуй, главное: сервер реинкарнаций. Это процесс, выступающий родительским по отношению к процессам всех драйверов и сервисов. Которые он запускает при старте, а в дальнейшем отслеживает состояние. Если процесс какого-либо драйвера или сервиса в силу неких причин самопроизвольно «умирает», он запускает его вновь. Если один из драйверов или сервисов начинает вести себя «нехорошо», сервер реинкарнаций в состоянии убить соответствующий ему процесс и тут же запустить его заново, обеспечивая, таким образом прозрачное для пользователя самовосстановление системы при отказе почти любого драйвера устройства или системной службы.
Очевидно, что такая, достаточно сложная, схема взаимодействия драйверов и системных служб не может не привести к некоторой потере производительности по сравнению с обычными системами, где драйверы и сервисы сосуществуют в едином пространстве памяти, вне зависимости от того, пользовательском или «ядерном» (а подчас еще и вместе с ядром). То есть – неизбежно должны вызвать снижение быстродействия системы. В каких масштабах? Исследования команды Таненбаума дают ответ на этот вопрос, и к нему я еще вернусь. Но сначала сделаю маленькое отступление на тему, что такое быстродействие операционной системы вообще и с чем его едят, то есть – чем меряют.