Архитектура ОС

 

Большинство современных операционных систем представляют собой хорошо структурированные модульные системы, способные к развитию, расширению и переносу на новые платформы. Какой либо единой архитектуры ОС не существует, но существуют универсальные подходы к структурированию ОС.

Ядро и вспомогательные модули ОС

Наиболее общим подходом к архитектуре ОС является разделение всех ее модулей на 2 группы:

1)    ядро — модули, выполняющие основные функции ОС;

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

Модули ядра выполняют такие базовые функции ОС, как управление процессами, памятью, устройствами ввода-вывода и др. В состав ядра входят функции, решающие внутрисистемные задачи организации вычислительного процесса, такие как переключение контекстов, загрузка/выгрузка страниц, обработка прерываний. Эти функции недоступны для приложений. Приложения могут обращаться к ядру с запросами — системными вызовами для открытия и чтения файла, вывода графической информации на дисплей и т.д. Функции ядра, которые могут вызываться приложениями, образуют интерфейс прикладного программирования — API. Для обеспечения высокой скорости работы ОС все модули ядра или большая их часть постоянно находятся в оперативной памяти, то есть являются резидентными. Обычно ядро оформляется в виде программного модуля некоторого специального формата, отличающегося от формата пользовательских приложений.

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

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

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

Некоторая программа может существовать определенное время как пользова­тельское приложение, а потом стать частью ОС, или наоборот. Ярким примером такого изменения статуса программы является Web-браузер компании Microsoft, который сначала поставлялся как отдельное приложение, затем стал частью операционных систем Windows NT 4.0 и Windows 95/98, а сегодня существует большая вероятность того, что по решению суда этот браузер снова превратится в самостоятельное приложение.

 

Рис. 1 – Нечеткость границы между ОС и приложениями

 

Вспомогательные модули ОС обычно подразделяются на следующие группы:

1)      утилиты — программы, решающие отдельные задачи управления и сопровождение компьютерной системы (программа сжатия дисков, архивирования и т.д.);

2)      системные обрабатывающие программы — текстовые или графические редакторы, компиляторы, компоновщики, отладчики;

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

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

Рис. 2 – Взаимодействие между ядром и вспомогательными модулями ОС

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

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

 

Ядро в привилегированном режиме

 

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

Для обеспечения привилегии ОС использует специальные средства аппаратной поддержки. Аппаратура компьютера должна поддерживать как минимум два режима работы — пользовательский режим (user mode) и приви­легированный режим, который также называют режимом ядра (kernel mode), или режимом супервизора (supervisor mode). Подразумевается, что операционная сис­тема или некоторые ее части работают в привилегированном режиме, а приложе­ния — в пользовательском режиме.

Так как ядро выполняет все основные функции ОС, то чаще всего именно ядро становится той частью ОС, которая работает в привилегированном режиме (рис. 3). Иногда это свойство — работа в привилегированном режиме — служит основным определением понятия «ядро».

Рис. 3. Архитектура операционной системы с ядром в привилегированном режиме

 

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

Очень важно, что механизмы защиты памяти используются операционной сис­темой не только для защиты своих областей памяти от приложений, но и для за­щиты областей памяти, выделенных ОС какому-либо приложению, от осталь­ных приложений. Говорят, что каждое приложение работает в своем адресном пространстве. Это свойство позволяет локализовать некорректно работающее приложение в собственной области памяти, так что его ошибки не оказывают влияния на остальные приложения и операционную систему. Между количеством уровней привилегий, реализуемых аппаратно, и количест­вом уровней привилегий, поддерживаемых ОС, нет прямого соответствия. Так, на базе четырех уровней, обеспечиваемых процессорами компании Intel опера­ционная система OS/2 строит трехуровневую систему привилегий, а операцион­ные системы Windows NT, UNIX и некоторые другие ограничиваются двух­уровневой системой.

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

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

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

Рис. 4. Смена режимов при выполнении системного вызова к привилегированному ядру

 

Архитектура ОС, основанная на привилегированном ядре и приложениях поль­зовательского режима, стала, по существу, классической. Ее используют многие популярные операционные системы, в том числе многочисленные версии UNIX, VAX VMS, IBM OS/390, OS/2, и с определенными модификациями — Win­dows.

В некоторых случаях разработчики ОС отступают от этого классического вари­анта архитектуры, организуя работу ядра и приложений в одном и том же ре­жиме. Так, известная специализированная операционная система NetWare компании Novell использует привилегированный режим процессоров Intel x86/ Pentium как для работы ядра, так и для работы своих специфических приложе­ний — загружаемых модулей NLM (рис. 5). При таком построении операционной системы, обра­щения приложений к ядру выполняются быстрее, так как нет переключения ре­жимов, однако при этом отсутствует надежная аппаратная защита памяти, занимаемой модулями ОС, от некорректно работающего приложения. Разра­ботчики NetWare пошли на такое потенциальное снижение надежности своей операционной системы, поскольку ограниченный набор ее специализирован­ных приложений позволяет компенсировать этот архитектурный недостаток за счет тщательной отладки каждого приложения.

 

Рис. 5. Упрощенная архитектура операционной системы NetWare

 

В одном режиме работают также ядро и приложения тех операционных систем, которые разработаны для процессоров, вообще не поддерживающих привилеги­рованного режима работы. Наиболее популярным процессором такого типа был процессор Intel 8088/86, послуживший основой для персональных компьютеров компании IBM. Операционная система MS-DOS, разработанная компанией Mic­rosoft для этих компьютеров, состояла из двух модулей msdos.sys и io.sys, состав­лявших ядро системы (хотя название «ядро» для этих модулей не употребля­лось, по своей сути они им являлись), к которым с системными вызовами обращались командный интерпретатор command.com, системные утилиты и при­ложения. Архитектура MS-DOS соответствует архитектуре ОС, приведенной на рис. 2. Некорректно написанные приложения вполне могли разрушить основ­ные модули MS-DOS, что иногда и происходило, но область использования MS-DOS (и многих подобных ей ранних операционных систем для персональных компьютеров, таких как MSX, СР/М) и не предъявляла высоких требований к надежности ОС.

Появление в более поздних версиях процессоров Intel (начиная с 80286) возможности ра­боты в привилегированном режиме не было использовано разработчиками MS-DOS. Эта ОС всегда работает на процессорах данного типа в так называемом реальном режиме, в ко­тором эмулируется процессор 8086/88. Не следует считать, что реальный режим является синонимом пользовательского режима, а привилегированный режим — его альтернативой. Реальный режим был реализован только для совместимости поздних моделей процессо­ров с ранней моделью 8086/88 и альтернативой ему является защищенный режим работы процессора, в котором становятся доступными все особенности процессоров поздних мо­делей, в том числе и работа на одном из четырех уровней привилегий.

 

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

 

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

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

Рис. 10. Перенос основного объема функций ядра в пользовательское пространство

 

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

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

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

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

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

 

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

 

 

 

Многослойная структура ОС

 

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

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

Рис. 6. Трехслойная схема вычислительной системы

 

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

Такая организация системы имеет много достоинств:

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

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

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

Рис. 7. Концепция многослойного взаимодействия

 

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

Ядро может состоять из следующих слоев (рис. 8):

1. Средства аппаратной поддержки ОС. До сих пор об операционной системе говорилось как о комплексе программ, тем не менее, часть функций ОС может выполняться и аппаратными средствами. Поэтому иногда можно встретить определение операционной системы как совокупности программных и аппаратных средств, что и отражено на рис. 8. К операционной системе относят, не все аппаратные устройства компьютера, а только средства аппаратной поддержки ОС, то есть те, которые прямо участвуют в организации вычислительных процессов: средства поддержки привилегированного режима, систему прерываний, средства переключения контекстов процессов, средства защиты областей памяти и т. п. Информация о незавершенных операциях в/в, кодами ошибок выполняемых процессом системных вызовов называется контекстом процесса. При смене процесса происходит переключение контекстов.

 

Рис. 8. Многослойная структура ядра ОС

 

2. Машинно-зависимые компоненты ОС. Этот слой образуют программные модули, в которых отражается специфика аппаратной платформы компьютера. Это позволяет разрабатывать вышележащие слои на основе машинно-независимых модулей, существующих в единственном экземпляре для всех типов аппаратных платформ, поддерживаемых данной ОС. В идеале этот слой полностью экранирует вышележащие слои ядра от особенностей аппаратуры. Примером экранирующего слоя может служить слой HAL операционной системы Windows NT. Так HAL (Hardware Abstraction Layer) динамически загружаемая библиотека (DLL) позволяет исполняющей системе Windows NT функционировать на аппаратных платформах разных поставщиков, что обеспечивает максимальную переносимость данной ОС. HAL в Windows NT является абстрагирующим слоем, т.е. своеобразной VM над аппаратными средствами компьютера. Таким образом, ОС пишется один раз, а выполняется на различных аппаратных платформах, переписывается сравнительно небольшая часть – слой аппаратных абстракций HAL.

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

 

Рис. 9. Перенос операционной системы на разные аппаратные платформы

 

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

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

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

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

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

Для компьютеров па основе процессоров Intel x86/Pentium разработка экрани­рующего машинно-зависимого слоя ОС несколько упрощается за счет встроен­ной в постоянную память компьютера базовой системы ввода-вывода — BIOS. BIOS содержит драйверы для всех устройств, входящих в базовую конфигура­цию компьютера: жестких и гибких дисков, клавиатуры, дисплея и т. д. Эти драйверы выполняют весьма примитивные операции с управляемыми устройст­вами, например чтение группы секторов данных с определенной дорожки диска, но за счет этих операций экранируются различия аппаратных платформ персо­нальных компьютеров и серверов на процессорах Intel разных производителей. Разработчики операционной системы могут пользоваться слоем драйверов BIOS как частью машинно-зависимого слоя ОС, а могут и заменить все или часть драйверов BIOS компонентами ОС.

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

4. Менеджеры ресурсов. Этот слой состоит из мощных функциональных модулей, реализующих стратегические задачи по управлению основными ресурса­ми вычислительной системы. Обычно на данном слое работают менеджеры (называемые также диспетчерами) процессов, ввода-вывода, файловой систе­мы и оперативной памяти. Разбиение на менеджеры может быть и несколько иным, например менеджер файловой системы иногда объединяют с менедже­ром ввода-вывода, а функции управления доступом пользователей к системе в целом и ее отдельным объектам поручают отдельному менеджеру безопас­ности. Каждый из менеджеров ведет учет свободных и используемых ресур­сов определенного типа и планирует их распределение в соответствии с за­просами приложений. Например, менеджер виртуальной памяти управляет перемещением страниц из оперативной памяти на диск и обратно. Менеджер должен отслеживать интенсивность обращений к страницам, время пребыва­ния их в памяти, состояния процессов, использующих данные, и многие дру­гие параметры, на основании которых он время от времени принимает реше­ния о том, какие страницы необходимо выгрузить и какие — загрузить. Для исполнения принятых решений менеджер обращается к нижележащему слою базовых механизмов с запросами о загрузке (выгрузке) конкретных страниц. Внутри слоя менеджеров существуют тесные взаимные связи, отражающие тот факт, что для выполнения процессу нужен доступ одновременно к не­скольким ресурсам — процессору, области памяти, возможно, к определенно­му файлу или устройству ввода-вывода. Например, при создании процесса менеджер процессов обращается к менеджеру памяти, который должен выде­лить процессу определенную область памяти для его кодов и данных.

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

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

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

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

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