Жаропонижающие средства для детей назначаются педиатром. Но бывают ситуации неотложной помощи при лихорадке, когда ребенку нужно дать лекарство немедленно. Тогда родители берут на себя ответственность и применяют жаропонижающие препараты. Что разрешено давать детям грудного возраста? Чем можно сбить температуру у детей постарше? Какие лекарства самые безопасные?
В микроядерных операционных системах мы можем выделить центральный компактный модуль, относящийся к супервизорной части системы. Этот модуль имеет очень небольшие размеры и выполняет относительно небольшое количество управляющих функций, но позволяет передать управление на другие управляющие модули, которые и выполнят затребованную функцию. Микроядро - это минимальная главная (стержневая) часть операционной системы, служащая основой модульных и переносимых расширений. Микроядро само является модулем системного программного обеспечения, работающим в наиболее приоритетном состоянии компьютера и поддерживающим связи с остальной частью операционной системы, которая рассматривается как набор серверных приложений (служб).
В 90-е годы XX века было весьма распространенным убеждение, что большинство операционных систем следующих поколений будут строиться как микроядерные. Однако практика показывает, что это не совсем так. Разработчики желают иметь компактное микроядро, но при этом включить в него как можно больше функций, исполняемых непосредственно этим программным модулем. Ибо выполнение затребованной функции другим модулем, вызываемым из микроядра, приводит и к дополнительным задержкам, и к дополнительным сложностям. Более того, имеется масса разных мнений по поводу того, как следует организовывать службы операционной системы по отношению к микроядру; как проектировать драйверы устройств, чтобы добиться наибольшей эффективности, но сохранить функции
290______________________________ Глава 9. Архитектура операционных систем
драйверов максимально независимыми от аппаратуры; следует ли выполнять операции, не относящиеся к ядру, в пространстве ядра или в пространстве пользователя; стоит ли сохранять программы имеющихся подсистем (например, UNIX) или лучше отбросить все и начать с нуля.
Основная идея, заложенная в технологию микроядра заключается в том, чтобы создать необходимую среду верхнего уровня иерархии, из которой можно легко получить доступ ко всем функциональным возможностям уровня аппаратного обеспечения. При этом микроядро является стартовой точкой для создания всех остальных модулей системы. Все эти остальные модули, реализующие необходимые системе функции, вызываются из микроядра и выполняют сервисную роль. При этом они получают статус обычного процесса или задачи. Можно сказать, что микроядерная архитектура соответствует технологии клиент-сервер. Именно эта технология позволяет в большей мере и с меньшими трудозатратами реализовать перечисленные выше принципы проектирования операционных систем.
Важнейшая задача разработки микроядра заключается в выборе базовых примитивов, которые должны находиться в микроядре для обеспечения необходимого и достаточного сервиса. В микроядре содержится и исполняется минимальное количество кода, необходимое для реализации основных системных вызовов. В число этих вызовов входят передача сообщений и организация другого общения между внешними по отношению к микроядру процессами, поддержка управления прерываниями, а также ряд других весьма немногочисленных функций. Остальные системные функции, характерные для «обычных» (не микроядерных) операционных систем, обеспечиваются как модульные дополнения-процессы, взаимодействующие главным образом между собой и осуществляющие взаимодействие посредством передачи сообщений.
Для большинства микроядерных операционных систем основой для такой архитектуры выступает технология микроядра Mach. Эта операционная система была создана в университете Карнеги Меллон, и многие разработчики брали с нее пример.
Исполняемые микроядром функции ограничены в целях сокращения его размеров и максимизации количества кода, работающего как прикладная программа. Микроядро включает только те функции, которые требуются в целях определения набора абстрактных сред обработки для прикладных программ и организации совместной работы приложений. В результате микроядро обеспечивает только пять различных типов сервисов:
Управление виртуальной памятью;
Поддержка заданий и потоков;
Взаимодействие между процессами (Inter-Process Communication, IPC);
- управление поддержкой ввода-вывода и прерываниями;
Сервисы хоста (host) 1 и процессора.
1 Хост - главный компьютер. Нынче этим термином обозначают любой компьютер, имеющий IP-адрес.
Микроядерные операционные системы________________ 291
Другие подсистемы и функции операционной системы, такие как файловые системы, поддержка внешних устройств и традиционные программные интерфейсы, оформляются как системные сервисы либо получают статус обычных обрабатывающих задач. Эти программы работают как приложения на микроядре.
С применением концепции нескольких потоков выполнения на одно задание микроядро создает прикладную среду, обеспечивающую использование мультипроцессоров; при этом совсем не обязательно, чтобы машина была мультипроцессорной: на однопроцессорной машине различные потоки просто выполняются в разное время. Вся поддержка, требуемая для мультипроцессорных машин, сконцентрирована в сравнительно малом и простом микроядре.
Благодаря своим небольшим размерам и способности поддерживать остальные службы в виде обычных процессов, выполняющихся вместе с прикладными программами, сами микроядра проще, чем ядра монолитных или модульных операционных систем. С микроядром супервизорная часть операционной системы разбивается на модульные части, которые могут быть сконфигурированы целым рядом способов, позволяя строить большие системы добавлением частей к меньшим. Например, каждый аппаратно-независимый нейтральный сервис логически отделен и может быть сконфигурирован различными способами. Микроядра также облегчают поддержку мультипроцессоров созданием стандартной программной среды, которая может использовать несколько процессоров, если они есть, однако если их нет, работает на одном. Специализированный код для мультипроцессоров ограничен самим микроядром. Более того, сети из общающихся между собой микроядер могут быть использованы для операционной системной поддержки возникающего класса массивно параллельных машин.
В некоторых случаях использование микроядерного подхода на практике сталкивается с определенными сложностями, что проявляется в некотором замедлении скорости выполнения системных вызовов при передаче сообщений через микроядро по сравнению с классическим подходом. С другой стороны, можно констатировать и обратное. Поскольку микроядра малы и в значительной степени оптимизированы, при соблюдении ряда условий они позволяют обеспечить характеристики реального времени, требующиеся для управления устройствами и для высокоскоростных коммуникаций. Наконец, хорошо структурированные микроядра обеспечивают изолирующий слой для аппаратных различий, которые не маскируются применением языков программирования высокого уровня. Таким образом, они упрощают перенесение кода и увеличивают уровень его повторного использования.
Наиболее ярким представителем микроядерных операционных систем является операционная система реального времени QNX. Микроядро QNX поддерживает только планирование и диспетчеризацию процессов, взаимодействие процессов, обработку прерываний и сетевые службы нижнего уровня (подробнее об ОС QNX см. в главе 10). Это микроядро обеспечивает всего лишь пару десятков системных вызовов, но благодаря этому оно может быть целиком размещено во внутреннем кэше даже таких процессоров, как Intel 486. Как известно, разные версии этой операционной системы имели и разные объемы ядер - от 8 до 46 Кбайт.
292______________________________ Глава 9. Архитектура операционных систем
Чтобы построить минимальную систему QNX, требуется добавить к микроядру менеджер процессов, который создает процессы и управляет ими и памятью процессов. Чтобы операционная система QNX была применима не только во встроенных и бездисковых системах, нужно добавить файловую систему и менеджер устройств. Эти менеджеры исполняются вне пространства ядра, так что ядро остается небольшим.
Микроядро – это минимальная часть операционной системы, являющаяся основой для модульных и переносимых расширений. Основная идея микроядра – создать необходимую среду верхнего уровня, из которой можно получить доступ ко всем функциям уровня аппаратного обеспечения .
В микроядре содержится минимальное количество кода, необходимое для реализации основных системных вызовов. К этим вызовам относятся передача сообщений и другие коммуникации между внешними по отношению к ядру процессами, управление прерываниями и некоторые другие функции. Остальные функции реализуются как модульные дополнения, взаимодействующие между собой с помощью сообщений.
Микроядро работает с наивысшим приоритетом и обеспечивает работу остальной части операционной системы как набора серверных приложений. Технология микроядра Mach (мэк) создана в университете Карнеги Меллон и служит основой многих операционных систем.
Функциональность микроядра ограничена с целью сокращения его размеров и перевода большей части операционной системы в ранг прикладной программы. Обычно микроядро поддерживает пять различных типов сервисов :
Управление виртуальной памятью,
Управление заданиями и потоками,
Межпроцессные коммуникации (IPC – inter-process communication),
Управление вводом-выводом и прерываниями,
Обеспечение клиент-серверного сервиса.
Другие функции операционной системы размещаются в других сервисах ОС, работающих как приложения микроядра.
Суть микроядерной архитектуры состоит в следующем . В привилегированном режиме работает только очень небольшая часть операционной системы, называемая микроядром. Микроядро защищено от остальных частей ОС и от приложений. Набор функций микроядра соответствует функциям слоя базовых механизмов обычного ядра. Это те функции, которые нельзя выполнить в пользовательском режиме. На рисунке 1.2 показан механизм переноса основного объема функций ядра в пространство пользователя .
Благодаря своим размерам и способности поддерживать стандартные сервисы программирования микроядро проще ядер монолитных или модульных операционных систем.
Рисунок 4.1 – Перенос основного объема функций ядра в пространство пользователя
Все остальные функции ядра оформляются в виде приложений, работающих в пользовательском режиме. Однозначных рекомендаций о том, какие из системных функций следует выполнять в привилегированном режиме, а какие в пользовательском, не существует.
Менеджеры ресурсов, вынесенные в пользовательский режим, называются серверами ОС, так как их основным назначением является обслуживание запросов приложений и других модулей ОС. Для реализации этого механизма необходимо наличие в ОС эффективного способа вызова процедур одного процесса из другого. Поддержка этого механизма и является основной функцией микроядра.
На рисунке 4.2 показан механизм обращения к функциям ОС, оформленных в виде серверов. Клиент, которым может быть либо прикладная программа, либо другой компонент операционной системы, запрашивает выполнение некоторой функции у соответствующего сервера, посылая ему сообщение. Непосредственная передача сообщений между приложениями невозможна, так как их адресные пространства изолированы друг от друга. Микроядро, выполняющееся в привилегированном режиме, имеет доступ ко всем адресным пространствам, поэтому может работать в качестве посредника. Таким образом, работа микроядерной операционной системы соответствует модели клиент-сервер, в которой роль транспортных средств выполняет микроядро.
Наиболее ярким представителем микроядерных ОС является операционная система реального времени QNX. Микроядро QNX планирует только планирование и диспетчеризацию процессов, их взаимодействие, обработку прерываний и сетевые службы нижнего уровня. Такое микроядро обеспечивает лишь два десятка системных вызовов и имеет размер от 8 до 46 килобайт.
Рисунок 4.2 – Реализация системного вызова в микроядерной архитектуре
Для построения минимальной системы QNX к микроядру следует добавить менеджер процессов, который создает процессы, управляет ими и их памятью. Для применения QNX в настольной ПЭВМ, к микроядру следует добавить также файловую систему и менеджер устройств.
Все эти менеджеры выполняются вне пространства ядра, так что ядро остается небольшим.
Рассмотрим кратко достоинства и недостатки микроядерных ОС. К достоинствам их можно отнести:
Переносимость, обусловленная тем, что весь машинно-зависимый код изолирован в микроядре,
Расширяемость, обусловленная ограниченным набором четко определенных интерфейсов микроядра; добавление новой подсистемы требует разработки нового приложения, что никак не затрагивает целостность микроядра,
Надежность, обусловленная тем, что каждый сервер выполняется в виде отдельного процесса в собственной области памяти, что защищает его от других серверов ОС (в традиционной операционной системе все модули могут влиять друг на друга); повышению надежности способствует также уменьшенный объем кода микроядра,
Пригодность для распределенных вычислений, так как использует механизмы клиент-серверного взаимодействия, причем серверы микроядерной ОС могут находиться как на одном, так и на разных компьютерах.
Основным недостатком микроядерной ОС является сниженная по сравнению с классической ОС производительность. Дело в том, что при классической организации ОС выполнение системного вызова сопровождается двумя переключениями режимов, а при микроядерной архитектуре – четырьмя. Ситуация иллюстрируется рисунком 4.3.
Рисунок 4.3 – Смена режимов при выполнении системного вызова
Серьезность этого недостатка хорошо иллюстрирует история развития Windows NT . В версиях 3.1 и 3.5 диспетчер окон, графическая оболочка и высокоуровневые драйверы графических устройств были включены в состав сервера пользовательского режима, и вызов этих функций осуществлялся в соответствии с микроядерной схемой. Однако, разработчикам стало ясно, что такой механизм существенно снижает быстродействие системы, поэтому в версии 4.0 перечисленные выше модули были включены в ядро. Этот факт отдалил ОС от идеальной микроядерной архитектуры, но сделал систему более производительной.
Недавно Эндрю Татенбаум, профессор Амстердамского свободного университета, автор учебной и миниатюрной Unix системы Minix, вновь оказался в центре событий благодаря эпистолярному жанру. В своем письме Интел он поблагодарил компанию за использование Minix, посетовал на то, что та не трубила об этом на каждом шагу и заявил, что из-за этого мало кто знает о том, что Minix - на сегодняшний день самая популярная ОС на свете .
Надо отдать должное профессору, он умеет выбирать адресата, время и место для того, чтобы вызвать громкий и продолжительный эффект с помощью простого сообщения, отправленного по электронной почте. Его предыдущим корреспондентом был Линус Торвальдс, а их переписка о монолитном и микро ядре вошла в анналы истории ИТ. Без этого трудно понять, почему Эндрю Таненбаум так экзальтирован из-за мнимого успеха Миникс, которая всего лишь в течении десятка лет обеспечивала работу интеловского бэкдора IME .
Рождение Linux и критика монолитного ядра
26 лет назад программирования для Unix было нетривиальным делом для обычного студента, так как все разновидности Unix были платными. Чтобы освоить эту операционную систему Линус решает поставить Minix. Интернет в ту пору еще только зарождался, заказ ОС шел через обычную почту, так же как и доставка. Ради Minix пришлось раскошелиться на 169 долларов.
У меня возникло множество претензий к Minix. Хуже всего была эмуляция терминала, очень важная для меня программа, потому что именно ее я использовал для подключения к университетскому компьютеру. Я зависел от этой эмуляции каждый раз, когда связывался с университетским компьютером, чтобы поработать с мощной Unix-системой или просто выйти в онлайн.
Вскоре будущий создатель Linux обнаружил серьезные недостатки Minix. Так как это был всего лишь обучающий вариант Unix, то профессор преднамеренно исковеркал ее. Многие из этих недостатков можно было устранить заплаткой самого известного хакера Minix Брюса Эванса, но для того, чтобы ее поставить нужно было изрядно провозиться. Самым же существенным недостатком для Линуса была программа эмуляции терминала, которую пришлось заменить на свою собственную. Затем понадобился драйвер файловой системы и понеслось, ядро новой ОС зародилось по принципу каши из топора.
25 августа 1991 г. Линус отправляет свое знаменитое сообщение о том, что работает над бесплатной операционной системой, но это будет не такой крупный и профессиональный проект как GNU . Помимо всего прочего внимание заслуживает тот факт, что этот и другие ранние анонсы свое операционной системы Линус отправляет в конференцию Minix, оттягивая на себя пользователей последней.
Эндрю Таненбаум до поры до времени никак на это не реагировал, но Linux рос как снежный ком. Уже в январе 1992 г. вышла версия 0.12, в котором была реализована страничная подкачка на диск - то чего не было в Minix. Вскоре после этого профессор снизошел до выскочки, чтобы лично ему ответить и вот 29-го января Линус получает сообщение в конференцию comp.os.minix с нравоучительным содержанием. Начало было обнадеживающим.
From: [email protected] (Andy Tanenbaum)
То: Newsgroups: comp.os.minix
Subject: LINUX устарела
Date: 29 Jan 92 12:12:50 GMT
Я тут на пару недель уезжал в США, поэтому не писал особенно о LINUX (не то чтобы я стал писать, если бы и был здесь). Однако теперь хочу сделать несколько замечаний.
Как большинство из вас знает, для меня MINIX – хобби, которым я занимаюсь по вечерам, когда мне надоедает писать книжки, а по CNN не показывают никаких войн, революций или парламентских слушаний. Моя основная работа – преподавание и исследования в области операционных систем.
Далее следовали справочные сведения о монолитном ядре, микроядре и об ОС, исповедующих тот, или иной принцип. Затем следовал несостоятельный с точки зрения логики довод о том, что среди специалистов по разработке операционных систем споры по данному вопросы уже прекратились ввиду явного преимущества микроядра. Дальше декларации о том, что Minix прогрессивна, а Linux - возврат в 1970-е. Кроме того, Linux привязан к одной архитектуре в то время как Minix был перенесен с Intel процессоров на другие платформы: Atari, Amiga, Macintosh, SPARC и NS32016.
Я мог бы многое рассказать о сравнительных преимуществах этих двух подходов, но достаточно сказать, что среди специалистов по разработке операционных систем споры уже закончились. Микроядро победило. Minix – система с микроядром. Файловая система и управление памятью – это отдельные процессы, которые работают вне ядра. Ввод-вывод тоже выполняется отдельно. LINUX – монолитная система. Это большой шаг назад, в 70-е. годы .
В начале 90-х микроядро действительно было в фаворе у проектировщиков операционных систем. По их мнению ядро ОС должно быть минимальным и содержать лишь самое необходимое: управление памятью, планировщик и IPC, а все остальное реализуется в виде сервисов. Разбив целое на множество простых частей, сложность исчезает, а легковесные сервисы без труда обмениваются данными с микроядром. Сбой в драйвере файловой системы или сетевой карты, таким образом элементарно восстанавливался перезагрузкой соответствующего сервиса.
Линус принимает вызов
Линус придерживался другого мнения на сей счет. Отдавая должное элегантности и изяществу архитектуры микроядра с теоретической точки зрения, он тем не менее считал микроядро не пригодным для практических целей. Мнимая простота микроядра оборачивается тем, что взаимодействие и интерфейс между простыми частями микроядра создает сложности, которые нивелируют все ее «бумажные» преимущества. В своем ответе он изложил свое видение по данному вопросу. После дерзких выпадов против своего оппонента Линус переходит к сути.
From: [email protected] (Linus Benedict Torvalds)
Subject: Re: LINUX устарела
Date: 29 Jan 92 23:14:26 GMT
Organization: University of Helsinki
...
Да, linux – монолитная система, и я согласен, что микроядро лучше. Если бы у вашего сообщения не был такой спорный заголовок, я бы, вероятно, согласился с большинством ваших высказываний. С теоретической (и эстетической) точки зрения linux проигрывает. Если бы ядро GNU было готово прошлой весной, я бы и не взялся за свою разработку: беда в том, что оно не было готово тогда и не готово до сих пор. Linux выигрывает прежде всего потому, что она уже готова.
Затем перечисляет проблемы Minix с многозадачностью в файловой системе.
Если бы это было единственным критерием качества ядра, вы были бы правы. Однако вы не пишете о том, что микроядро в minix сделано плохо и возникают проблемы с многозадачностью (в ядре). Если бы я сделал ОС, у файловой системы которой были бы проблемы с многозадачностью, я бы не стал так поспешно осуждать других: наоборот, я бы из кожи вон лез, чтобы все забыли о моем провале. Да, я знаю, что для minix есть масса заплаток, обеспечивающих многопоточную работу, но это лишь заплатки, и Брюс Эванс говорит, что все равно остается множество проблем синхронизации.
Перепалка в конференции продолжается, в спор вступают новые участники. Эндрю Таненбаум и Линус Торвальдсь продолжают спор, но уже более в более сдержанной манере. Ниже вольный перевод избранных цитат.
Эндрю Танебаум : Я нарочно написал Minix таким корявым, чтобы студенты могли гонять его на разнообразном и недорогом компьютерном железе, но дизайн у моей ОС норм., а не то что твой отсталый Linux. Его к тому же невозможно переносить на другие платформы. Я бы тебе на экзамене поставил пару.David Feustel : Ничего страшного, и у Эйнштейна были плохие отметки по математике и физике .
Ken Thompson : Пользователям до лампочки современное ли ПО у них на компьютере, производительность гораздо важнее. Да, будущее за микроядром, однако монолитное ядро проще состряпать. Впрочем, его и запороть проще, если писать код на скорую руку.
Randy Burns : Системные вызовы Linux совместимы с переносимыми ОС, так что жалобы на привязку к одной платформе неуместны. Наоборот, Linux закрывает брешь, позволяя нам использовать програмы GNU . Может быть через пару лет, когда Hurd и недорогие BSD системы получат распространение Linux и устареет, но сейчас мы можем наслаждаться gcc, bash, bison за бесценок и писать код для лучшей ОС .
Pete French : А разве микроядро и монолитное ядро не являются артефактами языка программирования, на котором написаны. В чем разница между микроядром, написанным на C и монолитным ядром - на OCCAM?
Линус Торвальдс : Ты старался так ради студентов, ну тогда понятно. Но с многозадачностью в твоей ОС все равно беда, как ни крути, а на моем «отсталом» монолитном Linux все летает. С переносимостью больших проблем не будет, так как Linux API переносимо - были бы желающие. А хорошие оценки мне и так не светят, я тут недавно с другим преподавателем архитектуры ОС повздорил.
Lawrence C. Foard : Теоретики такие теоретики. У них прекрасные идеи, но никто их них не удосужился их проверить на деле. Интелосвкие 32-битные процессоры уже почти 10 лет как доступны на рынке, но никто кроме Линуса не написал для них ОС , которую можно пощупать, без необходимости покупать Unix AT&T за 100,000$. Готовая ОС стоит десятка бумажных. Я уже сегодня могу писать код для Linux и экспериментировать как мне вздумается.
peter da silva : Прекрасно, что Linux существует и монолитное ядро - одна из причин того, что он был создан так быстро. Это мощный аргумент в пользу монолитного ядра и однако это не значит, что микроядро обязательно должно быть медленным, или что оно «бумажное».
Аргументы в пользу микроядра в то время действительно перевешивали, но на сегодняшний день опыт использования обоих принципов построения ОС
Лекция № 4. Микроядерная архитектура ОС
1. Концепция микроядерной архитектуры.
2. Преимущества и недостатки микроядерной архитектуры
3. Совместимость ОС
1. Концепция микроядерной архитектуры
Микроядерная архитектура является альтернативой классическому способу построения операционной системы. Под классической архитектурой в данном случае понимается рассмотренная выше структурная организация ОС, в соответствии с которой все основные функции операционной системы, составляющие многослойное ядро, выполняются в привилегированном режиме. При этом некоторые вспомогательные функции ОС оформляются в виде приложений и выполняются в пользовательском режиме наряду с обычными пользовательскими программами (становясь системными утилитами пли обрабатывающими программами). Каждое приложение пользовательского режима работает в собственном адресном пространстве и защищено тем самым от какого-либо вмешательства других приложений. Код ядра, выполняемый в привилегированном режиме, имеет доступ к областям памяти всех приложений, но сам полностью от них защищен. Приложения обращаются к ядру с запросами на выполнение системных функций.
Суть микроядерной архитектуры состоит в следующем. В привилегированном режиме остается работать только очень небольшая часть ОС, называемая микроядром (рис. 1). Микроядро защищено от остальных частей ОС и приложений. В состав микроядра обычно входят машинно-зависимые модули, а также модули, выполняющие базовые (но не все!) функции ядра по управлению процессами, обработке прерываний, управлению виртуальной памятью, пересылке сообщений и управлению устройствами ввода-вывода, связанные с загрузкой или чтением регистров устройств. Набор функций микроядра обычно соответствует функциям слоя базовых механизмов обычного ядра. Такие функции операционной системы трудно, если не невозможно, выполнить в пространстве пользователя.
Рис. 1. Перенос основного объема функций ядра в пользовательское пространство
Все остальные более высокоуровневые функции ядра оформляются в; виде приложений, работающих в пользовательском режиме. Однозначного решения о том, какие из системных функций нужно оставить в привилегированном режиме, а какие перенести в пользовательский, не существует. В общем случае многие менеджеры ресурсов, являющиеся неотъемлемыми частями обычного ядра - файловая система, подсистемы управления виртуальной памятью и процессами, менеджер безопасности и т. п., - становятся «периферийными» модулями, работающими в пользовательском режиме.
Работающие в пользовательском режиме менеджеры ресурсов имеют принципиальные отличия от традиционных утилит и обрабатывающих программ операционной системы, хотя при микроядерной архитектуре все эти программные компоненты также оформлены в виде приложений. Утилиты и обрабатывающие программы вызываются в основном пользователями. Ситуации, когда одному приложению требуется выполнение функции (процедуры) другого приложения, возникают крайне редко. Поэтому в операционных системах с классической архитектурой отсутствует механизм, с помощью которого одно приложение могло бы вызвать функции другого.
Совсем другая ситуация возникает, когда в форме приложения оформляется часть операционной системы. По определению, основным назначением такого приложения является обслуживание запросов других приложений, например создание процесса, выделение памяти, проверка прав доступа к ресурсу и т. д. Именно поэтому менеджеры ресурсов, вынесенные в пользовательский режим, называются серверами ОС, то есть модулями, основным назначением которых является обслуживание запросов локальных приложений и других модулей ОС. Очевидно, что для реализации микроядерной архитектуры необходимым условием является наличие в операционной системе удобного и эффективного способа вызова процедур одного процесса из другого. Поддержка такого механизма и является одной из главных задач микроядра.
Схематично механизм обращения к функциям ОС, оформленным в виде серверов, выглядит следующим образом (рис. 2). Клиент, которым может быть либо прикладная программа, либо другой компонент ОС, запрашивает выполнение некоторой функции у соответствующего сервера, посылая ему сообщение. Непосредственная передача сообщений между приложениями невозможна, так как их адресные пространства изолированы друг от друга. Микроядро, выполняющееся в привилегированном режиме, имеет доступ к адресным пространствам каждого из этих приложений и поэтому может работать в качестве посредника. Микроядро сначала передает сообщение, содержащее имя и параметры вызываемой процедуры нужному серверу, затем сервер выполняет запрошенную операцию, после чего ядро возвращает результаты клиенту с помощью другого сообщения. Таким образом, работа микроядерной операционной системы соответствует известной модели клиент-сервер, в которой роль транспортных средств выполняет микроядро.
https://pandia.ru/text/78/240/images/image003_9.jpg" width="520" height="224 src=">
Рис. 3. Смена режимов при выполнении системного вызова
Серьезность этого недостатка хорошо иллюстрирует история развития Windows NT. В версиях 3.1 и 3.5 диспетчер окон, графическая библиотека и высокоуровневые драйверы графических устройств входили в состав сервера пользовательского режима, и вызов функций этих модулей осуществлялся в соответствии с микроядерной схемой. Однако очень скоро разработчики Windows NT поняли, что такой механизм обращений к часто используемым функциям графического интерфейса существенно замедляет работу приложений и делает данную операционную систему уязвимой в условиях острой конкуренции. В результате в версию Windows NT 4.0 были внесены существенные изменения - все перечисленные выше модули были перенесены в ядро, что отдалило эту ОС от идеальной микроядерной архитектуры, но зато резко повысило ее производительность.
Этот пример иллюстрирует главную проблему, с которой сталкиваются разработчики операционной системы, решившие применить микроядерный подход, - что включать в микроядро, а что выносить в пользовательское пространство. В идеальном случае микроядро может состоять только из средств передачи сообщений, средств взаимодействия с аппаратурой, в том числе средств доступа к механизмам привилегированной защиты. Однако многие разработчики не всегда жестко придерживаются принципа минимизации функций ядра, часто жертвуя этим ради повышения производительности. В результате реализации ОС образуют некоторый спектр, на одном краю которого находятся системы с минимально возможным микроядром, а на другом - системы, подобные Windows NT, в которых микроядро выполняет достаточно большой объем функций.
3. Совместимость ОС
В то время как многие архитектурные особенности операционных систем непосредственно касаются только системных программистов, концепция множественных прикладных сред непосредственно связана с нуждами конечных пользователей - возможностью операционной системы выполнять приложения, написанные для других операционных систем. Такое свойство операционной системы называется совместимостью.
Двоичная совместимость и совместимость исходных текстов
Необходимо различать совместимость на двоичном уровне и совместимость на уровне исходных текстов. Приложения обычно хранятся в ОС в виде исполняемых файлов, содержащих двоичные образы кодов и данных. Двоичная совместимость достигается в том случае, когда можно взять исполняемую программу и запустить ее на выполнение в среде другой ОС.
Совместимость на уровне исходных текстов требует наличия соответствующего компилятора в составе программного обеспечения компьютера, на котором предполагается выполнять данное приложение, а также совместимости на уровне библиотек и системных вызовов. При этом необходима перекомпиляция имеющихся исходных текстов в новый исполняемый модуль.
Совместимость на уровне исходных текстов важна в основном для разработчиков приложений, в распоряжении которых эти исходные тексты всегда имеются. Но для конечных пользователей практическое значение имеет только двоичная совместимость, так как только в этом случае они могут использовать один и тот же коммерческий продукт, поставляемый в виде двоичного исполняемого кода, в различных операционных средах и на различных машинах. Для пользователя, купившего в свое время пакет (например, Lotus 1-2-3) для MS-DOS, важно, чтобы он мог запускать этот полюбившийся ему пакет без каких-либо изменений и на своей новой машине, работающей под управлением, например, Windows NT.
Обладает ли новая ОС двоичной совместимостью или совместимостью исходных текстов с существующими операционными системами, зависит от многих факторов. Самый главный из них - архитектура процессора, на котором работает новая ОС. Если процессор использует тот же набор команд (возможно, с некоторыми добавлениями) и тот же диапазон адресов, тогда двоичная совместимость может быть достигнута довольно просто. Для этого достаточно соблюдения следующих условий:
* вызовы функций API, которые содержит приложение, должны поддерживаться данной ОС;
* внутренняя структура исполняемого файла приложения должна соответствовать структуре исполняемых файлов данной ОС.
Гораздо сложнее достичь двоичной совместимости операционным системам, предназначенным для выполнения на процессорах, имеющих разные архитектуры. Помимо соблюдения приведенных выше условий необходимо организовать эмуляцию двоичного кода.
Пусть, например, требуется выполнить DOS-программу для IBM PC-совместимого компьютера на компьютере Macintosh. Компьютер Macintosh построен на основе процессора Motorola 680x0, а компьютер IBM PC - на основе процессора Intel 80x86. Процессор Motorola имеет архитектуру (систему команд, состав регистров и т. п.), отличную от архитектуры процессора Intel, поэтому ему непонятен двоичный код DOS-программы, содержащей инструкции этого процессора. Для того чтобы компьютер Macintosh смог интерпретировать машинные инструкции, которые ему изначально непонятны, на нем должно быть установлено специальное программное обеспечение - эмулятор.
Эмулятор должен последовательно выбирать каждую двоичную инструкцию процессора Intel, программным способом дешифрировать ее, чтобы определить, какие действия она задает, а затем выполнять эквивалентную подпрограмму, написанную в инструкциях процессора Motorola. Так как к тому же у процессора Motorola нет в точности таких же регистров, флагов и внутреннего арифметико-логического устройства, как в Intel, он должен также имитировать (эмулировать) все эти элементы с использованием своих регистров или памяти. Состояние эмулируемых регистров и флагов после выполнения каждой команды должно быть абсолютно таким же, как и в реальном процессоре Intel.
Это простая, но очень медленная работа, так как одна команда процессора Intel исполняется значительно быстрее, чем эмулирующая его последовательность команд процессора Motorola.
Трансляция библиотек
Выходом в таких случаях является использование так называемых прикладных программных сред. Одной из составляющих, формирующих прикладную программную среду, является набор функций интерфейса прикладного программирования API, которые операционная система предоставляет своим приложениям. Для сокращения времени на выполнение чужих программ прикладные среды имитируют обращения к библиотечным функциям.
Эффективность этого подхода связана с тем, что большинство сегодняшних программ работают под управлением GUI (графических интерфейсов пользователя) типа Windows, Mac или UNIX Motif, при этом приложения тратят большую часть времени, производя некоторые хорошо предсказуемые действия. Они непрерывно выполняют вызовы библиотек GUI для манипулирования окнами и для других связанных с GUI действий. Сегодня в типичных программах 60-80 % времени тратится на выполнение функций GUI и других библиотечных вызовов ОС. Именно это свойство приложений позволяет прикладным средам компенсировать большие затраты времени, потраченные на покомандное эмулирование программы. Тщательно спроектированная программная прикладная среда имеет в своем составе библиотеки, имитирующие внутренние библиотеки GUI, но написанные на «родном» коде. Таким образом достигается существенное ускорение выполнения программ с API другой операционной системы. Иногда такой подход называют трансляцией для того, чтобы отличать его от более медленного процесса эмулирования кода по одной команде за раз.
Например, для Windows-программы, работающей на Macintosh, при интерпретации команд процессора Intel 80x86 производительность может быть очень низкой. Но когда производится вызов функции GUI открытия окна, модуль ОС, реализующий прикладную среду Windows, может перехватить этот вызов и перенаправить его на перекомпилированную для процессора Motorola 680x0 подпрограмму открытия окна. В результате на таких участках кода скорость работы программы может достичь (а возможно, и превзойти) скорость работы на своем «родном» процессоре.
Чтобы программа, написанная для одной ОС, могла быть выполнена в рамках другой ОС, недостаточно лишь обеспечить совместимость API. Концепции, положенные в основу разных ОС, могут входить в противоречие друг с другом. Например, в одной операционной системе приложению может быть разрешено непосредственно управлять устройствами ввода-вывода, в другой - эти действия являются прерогативой ОС. Каждая операционная система имеет свои собственные механизмы защиты ресурсов, свои алгоритмы обработки ошибок и исключительных ситуаций, особую структуру процесса и схему управления памятью, свою семантику доступа к файлам и графический пользовательский интерфейс. Для обеспечения совместимости необходимо организовать бесконфликтное сосуществование в рамках одной ОС нескольких способов управления ресурсами компьютера.
Способы реализации прикладных программных сред
Создание полноценной прикладной среды, полностью совместимой со средой другой операционной системы, является достаточно сложной задачей, тесно связанной со структурой операционной системы. Существуют различные варианты построения множественных прикладных сред, отличающиеся как особенностями архитектурных решений, так и функциональными возможностями, обеспечивающими различную степень переносимости приложений.
Во многих версиях ОС UNIX транслятор прикладных сред реализуется в виде обычного приложения. В операционных системах, построенных с использованием микроядерной концепции, таких как, например, Windows NT или Workplace OS, прикладные среды выполняются в виде серверов пользовательского режима. А в OS/2 с ее более простой архитектурой средства организации прикладных сред встроены глубоко в операционную систему.
Один из наиболее очевидных вариантов реализации множественных прикладных сред основывается на стандартной многоуровневой структуре ОС. На рис. 4 операционная система OS1 поддерживает кроме своих «родных» приложений приложения операционных систем OS2 и OS3. Для этого в ее составе имеются специальные приложения - прикладные программные среды, - которые транслируют интерфейсы «чужих» операционных систем API OS2 и API OS3 в интерфейс своей «родной» операционной системы - API OS1. Так, например,
в случае, если бы в качестве OS2 выступала операционная система UNIX, а в качестве OS1 - OS/2, для выполнения системного вызова создания процесса forkO в UNIX-приложении программная среда должна обратиться к ядру операционной системы OS/2 с системным вызовом DosExecPgm().
Рис. 4. Прикладные программные среды, транслирующие системные вызовы
К сожалению, поведение почти всех функций, составляющих API одной ОС, как правило, существенно отличается от поведения соответствующих функций другой ОС. Например, чтобы функция создания процесса в OS/2 DosExecPgmO полностью соответствовала функции создания процесса forkO в UNIX-подобных системах, ее нужно было бы изменить, чтобы она поддерживала возможность копирования адресного пространства родительского процесса в пространство процесса-потомка. (При нормальном же поведении этой функции память процесса-потомка инициализируется на основе данных нового исполняемого файла.)
В другом варианте реализации множественных прикладных сред операционная система имеет несколько равноправных прикладных программных интерфейсов. В приведенном на рис. 5 примере операционная-система поддерживает приложения, написанные для OS1, OS2 и OS3. Для этого непосредственно в пространстве ядра системы размещены прикладные программные интерфейсы всех этих ОС: API OS1, API OS2 и API OS3.
В этом варианте функции уровня API обращаются к функциям нижележащего уровня ОС, которые должны поддерживать все три в общем случае несовместимые прикладные среды. В разных ОС по-разному осуществляется управление системным временем, используется разный формат времени дня, на основании собственных алгоритмов разделяется процессорное время и т. д. Функции каждого API реализуются ядром с учетом специфики соответствующей ОС, даже
если они имеют аналогичное назначение. Например, как уже было сказано, функция создания процесса работает по-разному для приложения UNIX и приложения OS/2. Аналогично при завершении процесса ядру также необходимо определять, к какой ОС относится данный процесс. Если этот процесс был создан по запросу UNIX-приложения, то в ходе его завершения ядро должно послать родительскому процессу сигнал, как это делается в ОС UNIX. А по завершении процесса OS/2, созданного с параметром EXEC_SYNC, ядро должно отметить, что идентификатор процесса не может быть повторно использован другим процессом OS/2. Для того чтобы ядро могло выбрать нужный вариант реализации системного вызова, каждый процесс должен передавать в ядро набор идентифицирующих характеристик.
https://pandia.ru/text/78/240/images/image006_0.jpg" width="527" height="282 src=">
Рис. 6. Микроядерный подход к реализации множественных прикладных сред
Создание в рамках одной операционной системы нескольких прикладных сред для выполнения приложений различных ОС представляет собой путь, который позволяет иметь единственную версию программы и переносить ее между операционными системами. Множественные прикладные среды обеспечивают совместимость на двоичном уровне данной ОС с приложениями, написанными для других ОС. В результате пользователи получают большую свободу выбора операционных систем и более легкий доступ к качественному программному обеспечению.