2015-01-07
638
Ядро состоит из набора фундаментальных функций [1] (в том числе, планирование потоков и синхронизация), которые расположены в файле Ntoskrnl.exe, и используются компонентами исполнительной системы и низкоуровневыми (аппаратно-зависимыми) средствами – диспетчерами прерываний и исключений, которые непосредственно «привязаны» к конкретной аппаратной платформе.
Ядро состоит из низкоуровневых четко определенных и хорошо предсказуемых примитивов и механизмов операционной системы, поддерживающих функции компонентов исполнительной системы более высокого уровня. Ядро отделено от исполнительной системы – оно реализует системные механизмы, но не участвует в принятии решений, связанных с системной политикой. Все такие решения, кроме планирования и диспетчеризации потоков, принимаются исполнительной системой.
Вне ядра исполнительная система представляет потоки и другие разделяемые ресурсы в виде объектов. Для каждого объекта необходим дескриптор, позволяющий манипулировать им, средства защиты и квоты, резервируемые при их создании, поэтому обслуживание объектов требует немалых ресурсов. Ядро реализует набор более простых объектов, называемых объектами ядра (Kernel Objects), что позволяет снизить издержки на их обслуживание. Объекты ядра позволяют ядру контролировать обработку данных процессором и поддерживают объекты исполнительной системы. Большинство объектов исполнительной системы инкапсулирует один или более объектов ядра, включая в себя их атрибуты, определенные ядром.
Одна из групп объектов ядра, называемых управляющими (Control Objects), определяет семантику управления различными функциями операционной системы. В эту группу входят объекты APC (Asynchronous Procedure Call – асинхронный вызов процедуры), DPC (Deferred Procedure Call – отсроченный вызов процедуры) и некоторые объекты, используемые диспетчером ввода-вывода (например, объект прерывания).
Другая группа объектов называется объекты диспетчера (Dispatcher Objects) реализует средства синхронизации, позволяющие планировать потоки. В эту группу входят поток ядра (Kernel Thread), мьютекс (Mutex), событие (Event), семафор (Semaphore), таймер (Timer), таймер ожидания (Waitable Timer), и некоторые другие. С помощью функций ядра исполнительная система создает объекты ядра, манипулирует ими и конструирует более сложные объекты, предоставляемые в пользовательском режиме.
Не менее важной задачей ядра является абстрагирование или изоляция исполнительной системы и драйверов устройств от особенностей конкретной аппаратной реализации вычислительной системы. К особенностям конкретной аппаратной реализации относятся различия в обработке прерываний и исключений, синхронизация нескольких процессоров и т. п.
Архитектура ядра нацелена на максимальную унификацию кода, даже для аппаратно-зависимых функций. Интерфейсы, поддерживаемые ядром, унифицированы и могут использоваться в различных аппаратных платформах и конфигурациях.
Однако при всем стремлении разработчиков сделать интерфейсы аппаратно-независимыми, некоторая часть кода должна работать непосредственно с конкретной аппаратурой. Одним из примеров аппаратно-специфического кода может служить интерфейс, предоставляющий поддержку буфера трансляции процессорного кэша. Различие кода здесь объясняется различной реализацией кэша в разных архитектурах.
Вторым примером может служить переключение контекста. Хотя алгоритм переключения контекста один и тот же (сохранить контекст предыдущего потока, загрузить контекст нового потока, запустить новый поток), однако, сам контекст зависит от аппаратной архитектуры (состояние процессора и его регистров), реализация этой функции зависит от аппаратуры.
Третьим примером может служить набор х86-специфичных интерфейсов для поддержки старых программ MS-DOS. Эти интерфейсы принципиально не являются переносимыми, так как в другой аппаратной архитектуре они просто отсутствуют.
Для того, чтобы операционная система Windows 2000 все-таки была переносимой между различными аппаратными архитектурами, в состав системы входит специальный компонент, который изолирует основные функции ядра системы от аппаратной конфигурации – уровень аппаратных абстракций.
Уровень аппаратных абстракций HAL
Уровень аппаратных абстракций (HAL – Hardware Abstraction Layer) является ключевым компонентом, обеспечивающим переносимость Windows 2000 между различными аппаратными архитектурами. HAL – это загружаемый модуль режима ядра (Hal.dll), предоставляющий низкоуровневый интерфейс с аппаратной платформой, на которой выполняется Windows 2000. Он скрывает от операционной системы специфику конкретной аппаратной платформы (интерфейсов ввода-вывода, контроллеров прерываний, механизмов взаимодействия между процессорами и т. д.), то есть, все функции, которые зависят от аппаратной архитектуры и конкретной ЭВМ.
Любая платформенно-зависимая информация, нужная внутренним компонентам Windows 2000 и драйверам устройств, получается от подпрограмм HAL, что и обеспечивает переносимость операционной системы. Именно поэтому подпрограммы HAL подробно описаны в Windows 2000 DDK.
В составе дистрибутива Windows 2000 имеется несколько модулей HAL (таблица 2.2), однако, при установке системы на жесткий диск компьютера копируется только один из модулей.
Таблица 2.2 – Список модулей HAL
| Имя файла HAL | Поддерживаемые системы |
| Hal.dll | Стандартные персональные компьютеры (ПК) |
| Halacpi.dll | ПК с ACPI (Advanced Configuration and Power Interface – Расширенный интерфейс управления питанием и конфигурациями) |
| Halapic.dll | ПК с APIС (Advanced Programmable Interrupt Controller – Расширенный программируемый контроллер прерываний) |
| Halaacpi.dll | ПК с ACPI и APIС |
| Halmps.dll | Многопроцессорные ПК |
| Halmacpi.dll | Многопроцессорные ПК с ACPI |
| Halborg.dll | Рабочие станции Silicon Graphics (в настоящее время не выпускаются) |
| Halsp.dll | Compaq System Pro |
Достаточно просто можно определить, какой именно модуль HAL используется в конкретном компьютере. Это можно сделать тремя способами:
1. Надо открыть файл \Winnt\repair\setup.log, найти в нем строку «…hal.dll =», и посмотреть имя, стоящее после знака равенства (например, "halaacpi.dll" – расшифровку см. в таблице 2.2).
2. Надо нажать правую кнопку мыши на значке My Computer (Мой компьютер) на рабочем столе, выбрать из контекстного меню пункт Properties (Свойства), открыть вкладку Hardware (Оборудование), нажать на кнопку Device Manager (Диспетчер устройств), выбрать устройство Computer (Компьютер) и посмотреть имя «драйвера устройства» (например, «Однопроцессорный компьютер с ACPI»).
3. Надо найти файл \Winnt\System32\HAL.DLL, нажать на нем правую кнопку мыши, выбрать пункт контекстного меню «Свойства», выбрать вкладку «Версия», и выбрать имя элемента «Внутреннее имя» – в поле «Значение» появится имя загруженного файла (например, halaacpi.dll).
Основные компоненты подсистемы ввода-вывода
Как уже говорилось, подсистема ввода-вывода в Windows 2000 состоит из нескольких компонентов исполнительной системы и драйверов устройств [1] (рисунок 2.3).
Рисунок 2.3 – Основные компоненты подсистемы ввода-вывода
Каждый из компонентов подсистемы ввода-вывода, изображенных на рисунке 2.3, выполняет свои функции.
- Диспетчер ввода-вывода подключает приложения и системные компоненты к виртуальным, логическим и физическим устройствам, а также определяет инфраструктуру, поддерживающую драйверы устройств.
- Драйвер устройства обычно предоставляет интерфейс ввода-вывода для устройств конкретного типа. Драйверы принимают от диспетчера ввода-вывода команды для управляемых ими устройств и уведомляют диспетчер ввода-вывода о выполнении этих команд. Драйверы могут использовать диспетчер ввода-вывода для пересылки команд ввода-вывода другим драйверам, реализующим интерфейс того же устройства.
- Диспетчер PnP взаимодействует с диспетчером ввода-вывода и драйверами шин (Bus Drivers) – одной из разновидностей драйверов устройств. Он управляет выделением аппаратных ресурсов, распознает устройства и реагирует на их подключение и отключение. Диспетчер PnP и драйверы шин отвечают за загрузку соответствующего драйвера при обнаружении нового устройства. Если устройство добавляется в систему, в которой не установлен нужный драйвер устройства, компоненты исполнительной системы, отвечающие за поддержку PnP, вызывают сервисы установки устройств, поддерживаемый диспетчером PnP пользовательского режима.
- Диспетчер электропитания также взаимодействует с диспетчеров ввода-вывода, управляет системой и драйверами устройств при их переходе в различные состояния энергопотребления.
- Процедуры поддержки Windows Management Instrumentation – Инструментарий управления Windows (WMI) образуют компонент доступа WDM (Windows Driver Model) WMI. Они позволяют драйверам устройств выступать в роли компонентов доступа, взаимодействуя со службой WMI пользовательского режима через компонент доступа WDM WMI.
- Реестр – это база данных, в которой хранится описание основных устройств, подключенных к системе, а также параметры инициализации драйверов и настройки конфигурации.
- INF -файлы используются для установки драйверов. Они связывают конкретное аппаратное устройство с драйвером, который и занимается управлением этим устройством. INF -файл состоит из инструкций, описывающих соответствующее устройство, исходное и целевое место нахождения файлов драйвера и дополнительную информацию о драйверах. CAT -файлы хранят цифровые подписи файлов драйверов, которые прошли испытание в лаборатории Microsoft Windows Hardware Quality Lab (WHQL).
- Уровень аппаратных абстракций (HAL) изолирует драйверы от специфических особенностей конкретной аппаратуры.
Большинство операций ввода-вывода не требуют участия всех указанных компонентов. Обычно запрос на ввод-вывод выдается приложением, этот запрос обрабатывается диспетчером ввода-вывода, одним или несколькими драйверами устройств и HAL.
В Windows 2000 потоки выполняют операции ввода-вывода над виртуальными файлами. Операционная система абстрагирует все запросы на ввод-вывод, скрывая тот факт, что конечное устройство ввода-вывода может и не быть устройством с файловой структурой. Это позволяет унифицировать интерфейс между приложениями и устройствами. Таким образом, виртуальный файл сопоставляется с любым устройством ввода или вывода, который рассматривается как файл. Приложения пользовательского режима (в любой исполнительной подсистеме) вызывают документированные функции, которые обращаются к внутренним функциям подсистемы ввода-вывода для чтения/записи файла, или для других операций.
Запросы, адресованные виртуальным файлам, диспетчер ввода-вывода направляет соответствующим драйверам устройств. Примерная схема обработки запроса ввода-вывода приведена на рисунке 2.4.
Рисунок 2.4 – Схема обработки типичного запроса ввода-вывода
Диспетчер ввода-вывода
Диспетчер ввода-вывода (I/O Manager) определяет модель доставки запросов ввода-вывода драйверам устройств. Подсистема ввода-вывода управляется пакетами. Большая часть запросов ввода-вывода представляется пакетами запросов ввода-вывода (I/O Request Packets, IRP), передаваемых от одного компонента подсистемы ввода-вывода к другому. (Исключением является быстрый ввод-вывод, при котором IRP не используются.) Подсистема ввода-вывода позволяет потоку приложения управлять сразу несколькими запросами ввода-вывода. IRP – это структура данных, которая содержит информацию, описывающую запрос ввода-вывода. Она используется диспетчером ввода-вывода следующим образом.
- Диспетчер ввода-вывода создает IRP, представляющий операцию ввода-вывода, передает указатель на IRP соответствующему драйверу и удаляет пакет по завершении операции ввода-вывода.
- Драйвер, получивший IRP, выполняет указанную в пакете операцию и возвращает IRP диспетчеру ввода-вывода.
- Диспетчер ввода-вывода либо завершает эту операцию, либо передает пакет другому драйверу для дальнейшей обработки.
Диспетчер ввода-вывода не только создает и уничтожает IRP, но и содержит общий для различных драйверов код, используемый ими при обработке ввода-вывода. Благодаря этому коду драйверы стали проще и компактнее. Например, одна из таких функций диспетчера ввода-вывода позволяет драйверу вызывать другие драйверы. Диспетчер управляет также буферами ввода-вывода и тайм-аутами драйверов, регистрирует устанавливаемые в систему файловые системы. Диспетчер ввода-вывода предоставляет драйверам около сотни готовых функций.
Диспетчер ввода-вывода предоставляет также гибкие сервисы ввода-вывода, используя которые подсистемы окружения (Win32, POSIX) реализуют свои функции. В их число входят, например, сервисы асинхронного ввода-вывода, позволяющие создавать масштабируемые серверные приложения.
Унификация и модульность интерфейса драйверов позволяет диспетчеру ввода-вывода вызывать любой драйвер, ничего не зная о его внутреннем устройстве и структуре. Как уже говорилось, операционная система обрабатывает запросы ввода-вывода, как работу с файлами. Драйвер преобразует запросы к виртуальному файлу в аппаратно-специфические запросы. Драйверы могут вызывать друг друга (через диспетчер ввода-вывода), обеспечивая многоуровневую независимую обработку запросов ввода-вывода.
Кроме стандартных функций открытия, закрытия, чтения и записи подсистема ввода-вывода Windows 2000 предоставляет ряд дополнительных функций, например, асинхронного, прямого и буферизованного ввода-вывода.
Драйверы устройств
Драйверы устройств являются загружаемыми модулями режима ядра (обычно это файлы с расширением .SYS). Драйверы образуют интерфейс между диспетчером ввода-вывода и соответствующим оборудованием. Эти драйверы выполняются в режиме ядра в одном из трех контекстов:
- в контексте пользовательского потока, инициировавшего функцию ввода-вывода,
- в контексте системного потока режима ядра,
- как результат прерывания (то есть, не в контексте процесса или потока, который был текущим на момент прерывания).
Ранее уже говорилось о том, что в Windows 2000 драйверы не работают непосредственно с оборудованием – они вызывают функции HAL. Драйверы обычно пишутся на С или на С++, поэтому при грамотном использовании процедур HAL они легко переносятся между архитектурами, поддерживаемыми Windows 2000 на уровне исходного кода. На уровне двоичных файлов они могут переноситься внутри семейства с одинаковой архитектурой. В Windows 2000 имеется несколько видов драйверов устройств [1].
- Драйверы аппаратных устройств, управляющие (через HAL) оборудованием. Они получают от физического устройства или из сети данные ввода или записывают в данные вывода. Такими драйверами являются драйверы шин, интерфейсов, устройств массовой памяти и т. д.
- Драйверы файловой системы – это драйверы Windows 2000, обрабатывающие запросы на файловый ввод-вывод и транслирующие их в запросы ввода-вывода для конкретных устройств,
- Драйверы фильтра файловой системы, которые отвечают за зеркалирование и шифрование дисков, перехват ввода-вывода и дополнительную обработку информации перед передачей ее на следующий уровень.
- Сетевые редиректоры и серверы, являющиеся драйверами файловых систем, которые передают запросы файловой системы на ввод-вывод другим компьютерам в сети и принимают от них аналогичные запросы.
- Драйверы протоколов, реализующие сетевые протоколы NCP/IP, NetBEUI и IPX/SPX.
- Драйверы потоковых фильтров ядра, предназначенные для обработки потоковых данных, например, при записи и воспроизведении аудио и видеоинформации.
Установка драйвера устройства – единственный способ добавить в систему дополнительный код режима ядра. Поэтому драйверы часто используются лишь для того, чтобы получить доступ к внутренним функциям или структурам данных, недоступных через Win32 API.
В Windows 2000 введена поддержка Plug and Play (PnP) и энергосберегающие технологии, а также расширена модель драйверов Windows NT, называемая Windows Driver Model (WDM). Windows 2000 может работать и с драйверами, унаследованными от Windows NT, но, очевидно, в этом случае не будет Plug and Play и энергосберегающих технологий.
С точки зрения WDM существует три типа драйверов:
- Драйвер шины (Bus Driver), обслуживающий контроллер шины, адаптер, мост или любые другие устройства, имеющие дочерние устройства. Для каждого типа шины (PCI, PCMCIA, USB) в системе имеется свой драйвер. Для поддержки новых шин (VMEbus, Multibus, Futurebus) используются драйверы сторонних разработчиков.
- Функциональный драйвер (Function Driver) – основной драйвер устройства, предоставляющий его функциональный интерфейс. Функциональный драйвер обладает наиболее полной информацией о своем устройстве. Обычно только этот драйвер имеет доступ к специфическим регистрам устройства.
- Драйвер фильтра (Filter Driver) поддерживает дополнительную функциональность устройства (или драйвера) или изменяет запросы ввода-вывода и ответы на них от других драйверов. Такие драйверы не обязательны. Их может быть несколько. Эти драйверы могут работать, как на более высоком уровне, чем функциональный драйвер или драйвер шины,
В среде WDM драйвер шины информирует диспетчер PnP об устройствах, подключенных к шине, а функциональный драйвер управляет устройством.
Драйвер фильтра низшего уровня обычно модифицирует поведение устройства, а драйвер фильтра высшего уровня придает устройству дополнительную функциональность. Так, драйвер низшего уровня может изменить требования устройства к аппаратным ресурсам, направляемые диспетчеру PnP, а драйвер высшего уровня для клавиатуры может обеспечить дополнительную защиту данных.
