Базовые механизмы ядра

Машинно-зависимые компоненты ОС

Этот слой образуют программные мо­дули, в которых отражается специфика аппаратной платформы компьютера, например,

1) количество типов прерываний и формат таблицы ссылок на процедуры обработки прерываний

2) состав регистров общего назначения

3) особенности подключения внешних устройств и др.

В идеале этот слой полностью экранирует вышележащие слои ядра от осо­бенностей аппаратуры.

Это позволяет разрабатывать вышележащие слои на основе машинно-независимых модулей, существующих в единственном эк­земпляре для всех типов аппаратных платформ, поддерживаемых данной ОС. Примером экранирующего слоя может служить слой HAL (хил) операционной сис­темы Windows NT.

Объем машинно-зависимых компонентов ОС зависит от того, насколько велики отличия в аппаратных платформах, для которых разрабатывается ОС.

Модули этого слоя выполняют наиболее примитивные опера­ции ядра, такие как:

· программное переключение процессов,

· дис­петчеризацию прерываний,

· перемещение страниц из памяти на диск и обрат­но и т. п.

Модули данного слоя не принимают решений о распределении

ресурсов. Они только отрабатывают принятые «наверху» решения, т.е. являются исполнительными механизмами для модулей верхних слоев. Например, решение о том, что в данный момент нужно прервать вы­полнение текущего процесса А и начать выполнение процесса В, принимает­ся менеджером процессов на вышележащем слое. При этом слою базовых механизмов передается только директива о том, что нужно выполнить переключение с текущего процесса на процесс В.

6. Менеджеры ресурсов. Этот слой состоит из мощных

функциональных моду­лей, реализующих стратегические задачи по управлению основными ресурса­ми вычислительной системы. Обычно на данном слое работают менеджеры (диспетчеры):

· процессов,

· ввода-вывода,

· файловой систе­мы и

· оперативной памяти.

Разбиение на менеджеры может быть и несколько иным, например,

1) менеджер файловой системы иногда объединяют с менедже­ром ввода-вывода, 2)

2) функции управления доступом пользователей к системе в целом и ее отдельным объектам поручают отдельному менеджеру безопас­ности.

Каждый из менеджеров ведет учет свободных и используемых ресур­сов определенного типа и планирует их распределение в соответствии с за­просами приложений. Например, менеджер виртуальной памяти управляет перемещением страниц из оперативной памяти на диск и обратно. Менеджер должен отслеживать:

1) интенсивность обращений к страницам,

2) время пребыва­ния их в памяти,

3) состояния процессов, использующих данные, и многие дру­гие

параметры, на основании которых он время от времени принимает реше­ния о том, какие страницы необходимо выгрузить и какие — загрузить.

Для исполнения принятых решений менеджер обращается к нижележащему слою базовых механизмов с запросами о загрузке (выгрузке) конкретных страниц.

Внутри слоя менеджеров существуют тесные взаимные связи, отражающие тот факт, что для выполнения процессу нужен доступ одновременно к не­скольким ресурсам — процессору, области памяти, возможно, к определенно­му файлу или устройству ввода-вывода. Например, при создании процесса менеджер процессов обращается к менеджеру памяти, который должен выде­лить процессу определенную область памяти для его кодов и данных.

7. Интерфейс системных вызовов. Этот слой является

самым верхним слоем ядра. Он взаимодействует непосредственно с приложениями и системными утили­тами, образуя прикладной программный интерфейс операционной системы (API). Функции API, обслуживающие системные вызовы, предоставляют доступ к ресурсам системы в удобной и компактной форме, без указания деталей их физического расположения.

Системные вызовы (system calls) – это интерфейс между операционной системой и пользовательской программой. Они создают, удаляют и используют различные объекты, главные из которых – процессы и файлы. Пользовательская программа запрашивает сервис у операционной системы, осуществляя системный вызов. Имеются библиотеки процедур, которые загружают машинные регистры определенными параметрами и осуществляют прерывание процессора, после чего управление передается обработчику данного вызова, входящему в ядро операционной системы. Цель таких библиотек – сделать системный вызов похожим на обычный вызов подпрограммы.

Основное отличие состоит в том, что при системном вызове задача переходит в привилегированный режим или режим ядра (kernel mode). Поэтому системные вызовы иногда еще называют программными прерываниями, в отличие от аппаратных прерываний, которые чаще называют просто прерываниями.

В этом режиме работает код ядра операционной системы, причем исполняется он в адресном пространстве и в контексте вызвавшей его задачи. Таким образом, ядро операционной системы имеет полный доступ к памяти пользовательской программы, и при системном вызове достаточно передать адреса одной или нескольких областей памяти с параметрами вызова и адреса одной или нескольких областей памяти для результатов вызова.

В большинстве операционных систем системный вызов осуществляется командой программного прерывания (INT). Программное прерывание – это синхронное событие, которое может быть повторено при выполнении одного и того же программного кода.

Например, в ОС UNIX с по­мощью системного вызова fd = open (" /doc/a.txt", 0_RDONLY) приложение от­крывает файл а.txt, хранящийся в каталоге /doc, а с помощью системного вызова read(fd, buffer, count) читает из этого файла в область своего адрес­ного пространства, имеющую имя buffer, некоторое количество байт. Для осуществления таких комплексных действий системные вызовы обычно об­ращаются за помощью к функциям слоя менеджеров ресурсов, причем для выполнения одного системного вызова может понадобиться несколько та­ких обращений.

Приведенное разбиение ядра ОС на слои является достаточно условным. В реальной системе количество слоев и распределение функций между ними может быть и иным (меньшим или большим). В системах, предназначенных для аппаратных платформ одного типа, например ОС NetWare, слой машинно-зависимых модулей обычно не выделяется, сливаясь со слоем базовых механизмов и, частично, со слоем менедже­ров ресурсов. Не всегда оформляются в отдельный слой базовые механизмы — в этом случае менеджеры ресурсов не только планируют использование ресурсов, но и самостоятельно реализуют свои планы.

Возможна и противоположная картина, когда ядро состоит из большего количе­ства слоев.

Способ взаимодействия слоев в реальной ОС также может отклоняться от опи­санной выше схемы.

Выбор количества слоев ядра является ответственным и сложным делом: увеличение числа слоев ведет к некоторому замедлению работы ядра за счет дополнительных накладных расходов на межслойное взаимодействие, а уменьшение числа слоев ухудшает расширяемость и логичность системы.

Обычно операционные системы, прошедшие долгий путь эволюционного развития, например многие версии UNIX, имеют неупорядоченное ядро с небольшим числом четко выделенных слоев, а у сравнительно «молодых» операционных систем, таких как Windows NT, ядро разделено на большее число слоев и их взаимодействие фор­мализовано в гораздо большей степени.

Итак, классическая архитектура:

1) все основные функции ОС, составляю­щие многослойное

ядро, выполняются в привилегированном режиме.

2) некоторые вспомогательные функции ОС оформляются в

виде приложений и выполняются в пользовательском режиме наряду с обычными пользователь­скими программами (становясь системными утилитами или обрабатывающими программами).

3) каждое приложение пользовательского режима работает в собст­венном адресном пространстве и защищено тем самым от какого-либо вмеша­тельства других приложений.

4) код ядра, выполняемый в привилегированном ре­жиме, имеет доступ к областям памяти всех приложений, но сам полностью от них защищен.

5)Приложения обращаются к ядру с запросами на выполнение сис­темных функций.

Альтернативой классическому способу по­строения операционной системы является

3.3 Микроядерная архитектура

Суть микроядерной архитектуры состоит в следующем.

В привилегированном режиме остается работать только очень небольшая часть ОС, называемая микро­ядром .

Приложения Приложения Утилиты ОС

пользователей Утилиты ОС пользователей

Серверы ОС

Пользовательский режим Пользоват.режим

Привилегированный режим Привилег.режим

Аппаратура

Микроядро защищено от остальных частей ОС и приложений. В состав микроядра обычно входят машинно-зависимые модули, а также моду­ли, выполняющие некоторые базовые (но не все!) функции ядра, связанные с загрузкой или чтением реги­стров устройств, по:

· управлению процессами;

· обработке прерываний;

· управлению виртуальной памятью;

· пересылке сообщений и;

· управлению устройствами ввода-вывода.

Все остальные более высокоуровневые функции ядра оформляются в виде при­ложений, работающих в пользовательском режиме.

Однозначного решения о том, какие из системных функций нужно оставить в привилегированном режиме, а какие перенести в пользовательский, не существует.

Многие ме­неджеры ресурсов, такие как фай­ловая система, подсистемы управления виртуальной памятью и процессами, менеджер безопасности и т. п., становятся «периферийными» модулями, рабо­тающими в пользовательском режиме.

Менеджеры ресурсов, оформленные в виде приложений, имеют принципи­альные отличия от традиционных утилит и обрабатывающих программ ОС. Утилиты и обрабатывающие программы вызываются в основном пользователями. Ситуации, когда одному приложению требуется выполнение функции (процедуры) другого приложения, возникают крайне редко. Поэтому в ОС с классической ар­хитектурой отсутствует механизм, с помощью которого одно приложение могло бы вызвать функции другого.

Совсем другая ситуация возникает, когда в форме приложения оформляется часть ОС. Основным назначением такого прило­жения является обслуживание запросов других приложений, например создание процесса, выделение памяти, проверка прав доступа к ресурсу и т. д. По­этому менеджеры ресурсов, вынесенные в пользовательский режим, называются серверами ОС. Это программные модули, основным назначением которых является об­служивание запросов локальных приложений и других модулей ОС. Для реализации микроядерной архитектуры необходимым условием являет­ся наличие в ОС удобного и эффективного способа вызова процедур одного процесса из другого. Поддержка такого механизма и является одной из главных задач микроядра.

Схематично механизм обращения к функциям ОС, оформленным в виде серве­ров, выглядит следующим образом .

Приложения

пользователей

Пользовательский

режим

Привилегированный

режим

Реализация системного вызова в микроядерной архитектуре

Клиент, которым может быть либо прикладная программа, либо другой компонент ОС, запрашивает выполне­ние некоторой функции у соответствующего сервера, посылая ему сообщение (запрос). Непосредственная передача сообщений между приложениями невозможна, так как их адресные пространства изолированы друг от друга. Микроядро, выпол­няющееся в привилегированном режиме, имеет доступ к адресным пространст­вам каждого из этих приложений и поэтому может работать в качестве посред­ника.

Алгоритм:

1) микроядро передает сообщение, содержащее имя и параметры вызываемой процедуры нужному серверу;

2) сервер выполняет запрошенную операцию;

3) микроядро возвращает результаты клиенту с помощью другого сообщения – ответа на запрос

Таким образом, работа микроядерной ОС соот­ветствует модели клиент-сервер, в которой роль транспортных средств выполняет микроядро.

Преимущества и недостатки микроядерной архитектуры.

Эта архитектура наиболее полно удовлетворяют большинству требований, предъявляемых к современным ОС, обладая:

· переносимостью,

· расширяемостью,

· надежностью и

· с возможностью поддержки распределенных приложений.

Высокая степень переносимости обусловлена тем, что весь машинно-зависимый код изолирован в микроядре, поэтому для переноса системы на новый процессор требуется меньше изменений и все они логически сгруппированы вместе.

Расширяемость присуща микроядерной ОС в очень высокой степени. В тради­ционных системах даже при наличии многослойной структуры нелегко удалить один слой и поменять его на другой по причине множественности и размытости интерфейсов между слоями. Добавление новых функций и изменение сущест­вующих требует хорошего знания операционной системы и больших затрат вре­мени. В то же время ограниченный набор четко определенных интерфейсов микроядра открывает путь к упорядоченному росту и эволюции ОС. Добавление новой подсистемы требует разработки нового приложения, что никак не затраги­вает целостность микроядра. Микроядерная структура позволяет не только до­бавлять, но и сокращать число компонентов операционной системы, что также бывает очень полезно. Например, не всем пользователям нужны средства без­опасности или поддержки распределенных вычислений, а удаление их из тра­диционного ядра чаще всего невозможно. Обычно традиционные операционные системы позволяют динамически добавлять в ядро или удалять из ядра только драйверы внешних устройств — ввиду частых изменений в конфигурации под­ключенных к компьютеру внешних устройств подсистема ввода-вывода ядра до­пускает загрузку и выгрузку драйверов «на ходу», но для этого она разрабатыва­ется особым образом (например, среда STREAMS в UNIX или менеджер ввода-вывода в Windows NT). При микроядерном подходе конфигурируемость ОС не вызывает никаких проблем и не требует особых мер — достаточно изменить файл с настройками начальной конфигурации системы или же остановить не нужные больше серверы в ходе работы обычными для остановки приложений средствами.

Использование микроядерной модели повышает надежность ОС. Каждый сер­вер выполняется в виде отдельного процесса в своей собственной области памя­ти и таким образом защищен от других серверов операционной систе, Этого нет в традиционной ОС, где все модули ядра могут влиять друг на дру­га. И если отдельный сервер терпит крах, то он может быть перезапущен без останова или повреждения остальных серверов ОС. Более того, поскольку серве­ры выполняются в пользовательском режиме, они не имеют непосредственного доступа к аппаратуре и не могут модифицировать память, в которой хранится и работает микроядро. Другим потенциальным источником повышения надеж­ности ОС является уменьшенный объем кода микроядра по сравнению с тради­ционным ядром — это снижает вероятность появления ошибок программиро­вания.

Модель с микроядром хорошо подходит для поддержки распределенных вычисле­ний, так как использует механизмы, аналогичные сетевым: взаимодействие кли­ентов и серверов путем обмена сообщениями. Серверы микроядерной ОС могут работать как на одном, так и на разных компьютерах. В этом случае при получе­нии сообщения от приложения микроядро может обработать его самостоятельно и передать локальному серверу или же переслать по сети микроядру, работаю­щему на другом компьютере. Переход к распределенной обработке требует минимальных изменений в работе операционной системы — просто локальный транспорт заменяется на сетевой.

За эти достоинства приходится платить снижением производительности.

При классической организации ОС выполне­ние системного вызова сопровождается двумя переключениями режимов.

При микроядерной организации — четырьмя.

Приложение Сервер ОС Приложение

Микроядро Микроядро

t t t t

Смена режимов при выполнении системного вызова

Таким образом, ОС на основе микроядра при прочих равных условиях всегда будет менее производительной, чем ОС с классическим ядром.

Именно по этой причи­не микроядерный подход не получил такого широкого распространения, которое ему предрекали.

Серьезность этого недостатка хорошо иллюстрирует история развития Windows NT. В версиях 3.1 и 3.5 диспетчер окон, графическая библиотека и высокоуров­невые драйверы графических устройств входили в состав сервера пользователь­ского режима, и вызов функций этих модулей осуществлялся в соответствии с микроядерной схемой. Однако очень скоро разработчики Windows NT поняли, что такой механизм обращений к часто используемым функциям графического интерфейса существенно замедляет работу приложений и делает данную опера­ционную систему уязвимой в условиях острой конкуренции. В результате в вер­сию Windows NT 4.0 были внесены существенные изменения — все перечислен­ные выше модули были перенесены в ядро, что отдалило эту ОС от идеальной микроядерной архитектуры, но зато резко повысило ее производительность.

Этот пример иллюстрирует главную проблему, с которой сталкиваются разра­ботчики операционной системы, решившие применить микроядерный подход, — что включать в микроядро, а что выносить в пользовательское пространство.

В идеальном случае микроядро может состоять только:

1) из средств передачи сооб­щений,

2) средств взаимодействия с аппаратурой, в том числе средств доступа к ме­ханизмам привилегированной защиты.

Однако многие разработчики не всегда жестко придерживаются принципа минимизации функций ядра, часто жертвуя этим ради повышения производительности. В результате реализации ОС обра­зуют некоторый спектр, на одном краю которого находятся системы с минималь­но возможным микроядром, а на другом — системы, подобные Windows NT, в которых микроядро выполняет достаточно большой объем функций.