1.1 Режимы ядра и пользователя Windows

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

Система Windows NT проектировалась, как переносимая операционная система, в которой весь код, зависимый от процессора и аппаратного обеспечения, изолирован в модуле, называемом уровнем аппаратных абстракций (hardware abstraction layer – HAL). Этот модуль рассматривается в разделе 1.3.1 далее в главе. Хотя Windows NT действительно раньше поддерживала несколько архитектур центральных процессоров, включая PowerPC и Alpha, современные версии Windows NT поддерживают только процессоры компании Intel и совместимые с ними модели (например, компании AMD). Некоторые базовые особенности архитектуры процессоров Intel рассматриваются далее в этом разделе, причем вместо описания всех возможностей архитектуры х86 затрагиваются лишь наиболее важные аспекты.

Архитектура Intel х86 поддерживает четыре режима работы: реальный, виртуальный х86, управления системой и защищенный.

В реальном режиме (real mode) каждый системный процесс имеет неограниченный доступ к первому мегабайту оперативной памяти. При загрузке процессор всегда запускается в реальном режиме. Процессор можно переключить в защищенный режим, установив соответствующий флаг в управляющем регистре; для обратного переключения флаг нужно сбросить. Реальный режим используется для инициализации Windows NT, однако переключение в защищенный режим происходит задолго до запуска приложений. В процессе развития семейства продуктов Windows NT роль реального режима становится все менее значимой. Как только процессор переключается в защищенный режим работы, Windows NT больше не переходит в реальный режим.

Виртуальный режим х86 (virtual х86 mode) предоставляет возможность выполнять несколько приложений реального режима, когда процессор работает в защищенном режиме. Операционная система Windows NT 4.0 поддерживает этот режим с помощью подсистемы NT Virtual DOS Machine

Рис. 1.1. Уровни привилегий архитектуры Intel х86

(NTVDM). Необходимость запуска приложений DOS под управлением Windows NT возникает все реже и реже, поэтому роль подсистемы NTVDM со временем становится все менее важной.

Защищенный режим (protected mode) представляет собой основной режим Windows NT. Он обладает четырьмя рабочими уровнями (рис. 1.1). Ha. уровне 0 (или кольце 0). который чаще всего называется режим ядра (kernel mode), доступны инструкции процессора и функции для обеспечения защиты памяти и работы с виртуальной памятью. Кроме того, на уровне 0 доступны привилегированные инструкции, например для управления регистрами процессора. Операционная система Windows NT не использует уровни (кольца) 1 и 2. Самый нижний уровень привилегий – уровень 3, или пользовательский режим (user mode). – обеспечивает наилучшую защиту, предотвращая доступ системных процессов к коду и памяти другого процесса.

Далее представлены некоторые функциональные возможности Windows NT для архитектуры х86.

Всей памятью можно управлять (выделять, считывать и записывать) посредством логических единиц, которые называются страницами . Дополни тельная информация приводится в разделе 1.3.3.6.

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

■ Страницы памяти, которые содержат код (в отличие от данных), могут быть отмечены как предназначенные только для чтения пользовательскими процессами и кодом на уровне ядра.

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

 

1.2 Процесс, контекст процесса и потоки

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

В Windows NT несколько процессов могут существовать одновременно; но только один процесс выполняется центральным процессором в определенный момент времени. Обратите внимание: драйверы вообще и драйверы систем хранения данных в частности не создают собственных процессов. Операционная система создает несколько процессов для своих нужд, а также определенные процессы в ответ на пользовательские команды, например когда пользователь запускает приложение, такое, как Microsoft Word или Microsoft Excel. Если драйвер вызывается во время работы процесса, считается, что он работает в контексте вызывающего процесса.

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

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

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

Поток может работать в пользовательском режиме и в режиме ядра. Потоки в режиме ядра могут создаваться только структурами, работающими в этом режиме, например драйверами устройств, и они всегда выполняются в режиме ядра. Потоки пользовательского режима обычно выполняются именно в этом режиме, кроме тех случаев, когда это происходит в режиме ядра после запроса к службе Windows NT, как уже отмечалось в разделе 1.1.

 

1.3 Архитектура Windows NT

Операционная система Windows NT проектировалась как модульная, многоуровневая архитектура, поддерживающая расширения за счет добавление новых функций. Архитектура позволяет добавлять поддержку новых устройств и новых возможностей, например шифрующей файловой системы (EFS). Архитектура системы позволяет добавлять поддержку приложений, которые основаны на других операционных системах, например OS/2 или POSIX. Конечно, обе эти системы более важны с исторической точки зрения, но они являются хорошим примером мЬдульной расширяемой архитектуры.

На рис. 1.2 показана высокоуровневая архитектура Windows NT. Как уже отмечалось во вступительном разделе, термин Windows NT используется для описания всех версий операционной системы Windows, основанных на технологии NT. В это семейство входят Windows NT 3. x, Windows NT 4.0, Windows 2000,' Windows XP и Windows Server 2003.

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

Рис. 1.2. Архитектура Windows NT

Режим ядра содержит все привилегированные процессы, которые выполняются на уровне 0 архитектуры Intel х86. Режим ядра Windows NT состоит из трех основных подсистем.

Уровень аппаратных абстракций?

Ядро Windows NT.

Выполняемый модуль Windows NT.

В следующих трех разделах эти компоненты рассматриваются более подробно.

1.3.1 Уровень аппаратных абстракций

Уровень аппаратных абстракций (Hardware Abstraction Layer – HAL) обеспечивает защиту данных за счет управления доступом к аппаратным ресурсам. Это единственный модуль операционной системы Windows NT, который содержит код, зависящий от аппаратного обеспечения (или от архитектуры процессора). Кроме того, для написания уровня аппаратных абстракций иногда применяется язык ассемблера. В целом уровень аппаратных абстракций предоставляет дополнительный уровень абстракции компонентам более

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

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

Поддержка ввода-вывода в контексте системной шины и прямого доступа к памяти (direct memory access – DMA). Уровень аппаратных абстракций выполняет трансляцию данных между внешней шиной и информацией об адресации Windows NT. Кроме того, предоставляется поддержка для информации о конфигурации шины.

Поддержка прерываний путем связывания (отображения) внешних прерываний с запросами прерываний (IRQ) Windows NT. Кроме того, предоставляется маскировка/демаскировка служб для прерываний.

1.3.2 Ядро Windows NT

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

помощь в синхронизации данных;

планирование выполнения потоков и процессов;

управление прерываниями и исключениями;

восстановление системы после аварийных ситуаций, например после отказа питания.

Данные ядра всегда находятся в оперативной памяти и никогда не выгружаются на диск, как это происходит с пользовательскими приложениями. Данные ядра не могут быть вытеснены другими данными. Это значит, что выполнение кода ядра не может быть прервано ради другого кода, если только ядро не выполняет это самостоятельно. Ядро представляет собой объектно- ориентированную систему, в которой используется два класса объектов.

1. Объекты-диспетчеры, которые позволяют управлять потоками и процессами и применяются для синхронизации различных потоков/процессов. В число объектов-диспетчеров входят мьютекс-флаги (mutex – это сокращение от «mutual exclusion», т.е. взаимное исключение), семафоры (semaphore) и таймеры (timer). Мьютекс-флаги являются объектами синхронизации и используются для синхронизации данных между двумя компонентами.

2. Объекты управления, например асинхронные вызовы процедур (asynchronous procedure calls – АРС) и процедуры обслуживания прерываний (interrupt service routines – ISR), которые рассматриваются более подробно в разделах 1.5.1 и 1.5.3.

1.3.3 Выполняемый модуль Windows NT

Выполняемый модуль (Windows NT Executive) обеспечивает работу ключевых функций, включая программные интерфейсы приложений (API), которые позволяют потокам из пользовательского режима в Windows NT взаимодействовать с ядром Windows NT для запроса на предоставление услуг. Как и ядро Windows NT, выполняемый модуль не может быть выгружен из памяти. Модуль управляет несколькими операциями, включая ввод-вы- вод данных, поддержку работы системы безопасности, межпроцессное взаимодействие, управление памятью и процессами, поддержку интерфейса Plug and Play, управление питанием, файловыми системами, объектами и графическими устройствами. Весь выполняемый модуль Windows NT размещен в одном файле – ntoskrnl. exe. Для выполнения задач модуля создается лишь несколько потоков. Обычно системный процесс из пользовательского режима запрашивает запуск службы, и модуль будет выполняться в контексте запросившего процесса. Примером потока, который создается выполняемым модулем, может служить поток сброса страниц на диск.

Выполняемый модуль Windows NT, в свою очередь, содержит следующие компоненты:

• диспетчер объектов;

• монитор ссылок безопасности;

• диспетчер процессов;

• подсистема Plug and Play;

• диспетчер энергопитания;

• диспетчер виртуальной памяти;

• диспетчер кэша.

1.3.3.1 Диспетчер объектов

Диспетчер объектов (Object Manager) Windows NT предоставляет свои услуги другим компонентам Windows NT, включая непосредственно выполняемый модуль (элементом которого диспетчер и является). Диспетчер объектов предоставляет службы для именования, создания, удаления, манипулирования и совместного использования объектов. Он активно сотрудничает с монитором ссылок безопасности, чтобы обеспечить соответствующий доступ к определенным объектам только пользователям и процессам с достаточными разрешениями. Соответствующий означает, что предоставляется доступ определенного типа, например доступ только для чтения. Каждый объект, созданный диспетчером объектов, имеет связанный с ним список управления доступом (access control list – ACL). На самом деле этот список представляет собой группу объектов, которые указывают разрешения, явно или неявно предоставленные пользователю или группе; кроме того, в список управления доступом могут входить объекты, ограничивающие права доступа для данного пользователя или группы.

Диспетчер объектов назначает дескриптор каждому созданному объекту. При этом обеспечивается уникальность дескрипторов и предоставляется возможность преобразования дескриптора в ссылку на уникальный объект. Но клиенты диспетчера объектов используют дескриптор в виде «непрозрачного» маркера без внутренней структуры. К объектам, с которыми работает диспетчер, относятся файлы, каталоги, порты, процессы, потоки, семафоры и объекты событий.

1.3.3.2 Монитор ссылок безопасности

Монитор ссылок безопасности (Security Reference Monitor) заведует проверкой доступа и протоколированием ресурсов. Проверка доступа выполняется на самом низком уровне, включая не только предоставление доступа, но и определение его типа, например доступ только для чтения или доступ для чтения и записи. Функциональность подсистемы безопасности обеспечивается объектно-ориентированной структурой Windows NT. При предоставлении доступа к объекту монитор ссылок безопасности сравнивает список управления доступом, который связан с объектом, с маркером (token) безопасности процесса перед тем, как предоставить или запретить доступ. Списки управления доступом бывают двух типов: явно или неявно разрешающие или запрещающие доступ. Монитор ссылок безопасности активно используется другими подсистемами выполняемого модуля Windows NT, например диспетчером объектов.

Кроме того, монитор ссылок безопасности предоставляет приложениям пользовательского режима услуги, аналогичные описанным. Монитор обеспечивает возможность генерации маркеров (на уровне процесса), которые могут использоваться для проверки безопасности и разрешений доступа, а также для генерации журналов аудита.

1.3.3.3 Диспетчер процессов

Диспетчер процессов (Process Manager) обеспечивает создание и удаление процессов и потоков, а также управление ими. Диспетчер не поддерживает иерархию компонентов; например, отношения между процессами вида «родитель-потомок» не отслеживаются. Эта работа ложится на компонент, который создал процесс. По аналогии представьте диспетчер файлов, который предоставляет возможность создания файла, однако внедрением этого файла в структуру каталогов должен заниматься пользователь диспетчера файлов. Диспетчер процессов пользуется услугами как диспетчера объектов, так и подсистемы безопасности. Для каждого запущенного процесса передается, как минимум, два вызова диспетчеру процессов: первый вызов для создания процесса, второй – для создания потока в пределах процесса, так как каждый процесс должен содержать хотя бы один поток.

1.3.3.4 Подсистема Plug and Play

На рис. 1.2 управление питанием и подсистема Plug and Play схематически размещены в едином прямоугольнике, что сделано для упрощения структуры диаграммы. На самом же деле это различные подсистемы, хотя и тесно взаимодействующие друг с другом.

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

корректное определение аппаратного обеспечения;

корректное определение динамического подключения или отключения аппаратного обеспечения;

выделение и настройка ресурсов для работы аппаратного обеспечения;

поиск и загрузка драйверов устройств;

поддержка механизма уведомления, с помощью которого определяется появление и удаление аппаратного обеспечения; этот механизм может использоваться программным обеспечением как в режиме ядра, так и в пользовательском режиме.

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

Подсистема Plug and Play играет очень важную роль в обнаружении устройств, присвоении устройствам идентификаторов, инициализации и добавлении/удалении устройств. В частности, Plug and Play отвечает за генерацию пакета запроса ввода-вывода (I/O request packet – IRP), который называется IRP_MN_QUERY_DEVICE_RELATIONSHIPS и передается драйверам шины. Этот пакет запроса ввода-вывода в презентациях Microsoft называется QDR. Пакет QDR применяется для перечисления устройств и создания стека устройств. Драйверы фильтрации иногда создаются для отслеживания функций QDR и исправления создаваемого списка устройств. В главе б рассматривается диспетчер разделов (Partition Manager), который обеспечивает подобные возможности в качестве драйвера фильтрации.

1.3.3.5 Диспетчер энергопитания

Диспетчер энергопитания (Power Manager) играет важную роль в предоставлении энергосберегающих функций, таких, как снижение оборотов вращения жестких дисков, накопителей для компакт-дисков и DVD, а также отключение питания мониторов и видеоадаптеров. Очевидно, что управление питанием гораздо важнее для портативных компьютеров, чем для серверов, но даже для серверов управление питанием применяется при обслуживании устройств, поддерживающих «горячую» замену, и при управлении устройствами резервного питания. Диспетчер энергопитания предоставляет интерфейс API для приложений более высокого уровня.

1.3.3.6 Диспетчер виртуальной памяти

Диспетчер виртуальной памяти (Virtual Memory Manager – VMM) предоставляет функции управления памятью, благодаря которым процессы могут использовать объем памяти, превышающий размер физической памяти, установленной на компьютере. Запросы приложений на выделение памяти регистрируются диспетчером виртуальной памяти. Если осталось недостаточно памяти, диспетчер виртуальной памяти переместит страницы памяти на жесткий диск, чтобы предоставить место для нового приложения. Если приложение стремится получить доступ к странице, которая отсутствует в физической памяти, диспетчер виртуальной памяти освобождает пространство в памяти перед перемещением страниц с диска в физическую оперативную память. Этот метод получил название подкачки страниц (paging).

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

В Windows NT 4.0 поддерживалось адресное пространство объемом 4 Гбайт, которое поровну распределялось между пользовательским режимом и режимом ядра. Верхние 2 Гбайт выделялись режиму ядра Windows NT, а нижние 2 Гбайт – пользовательскому режиму. В Windows 2000 Advanced Server параметры загрузки позволяют перераспределить адресное пространство, выделив 1 Гбайт режиму ядра и 3 Гбайт пользовательскому режиму. Приложения пользовательского режима следует переписать для использования дополнительного объема адресного пространства. Конечно, для 64-разрядной версии Windows NT подобного ограничения просто не существует.

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

1.3.3.7 Диспетчер кэша

Это неотъемлемый элемент подсистемы ввода-вывода, который работает в тесной связке с драйверами файловых систем и диспетчером виртуальной памяти. Диспетчер кэша Windows NT взаимодействует с файловой системой и ее драйверами. Подобный метод отличается от стратегии кэширования, свойственной Windows 95, которая предназначалась для взаимодействия непосредственно с дисковыми секторами. Диспетчер обслуживает все файловые системы, локальные и удаленные, с помощью единого кэша. Диспетчер кэша позволяет кэшировать несколько потоков данных из одного файла. Потоки данных относятся к возможностям файловой системы NT (NTFS) и рассматриваются в главе 6.

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

1.3.4 Подсистема ввода-вывода

Подсистема ввода-вывода отвечает за обработку запросов ввода-вывода и проектировалась для выполнения перечисленных далее задач.

Обеспечение работы сверхпроизводительных операций ответного ввода- вывода для одно- и многопроцессорных компьютеров.

Предоставление асинхронного ввода-вывода. Синхронный ввод-вывод осуществляется, по сути, в виде асинхронного запроса ввода-вывода, пс!>сле которого следует блокирующее ожидание завершения операции ввода-вывода.

Поддержка нескольких файловых систем, в частности CDFS, NTFS и UDFS.

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

Предоставление устройствам (и их драйверам) возможности подключения и отключения «на лету», без Перезагрузки (эта функция реализована в Windows 2000 и более новых версиях Windows NT).

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

Защита ресурсов, которые совместно используются несколькими процессами.

Подсистема ввода-вывода имеет модульную структуру (как и все остальные компоненты Windows NT) и состоит из следующих компонентов:

программный интерфейс приложений ввода-вывода (I/O API);

диспетчер ввода-вывода;

драйверы файловых систем;

другие драйверы (например, драйверы клавиатуры и драйверы дисков).

Далее эти модули рассматриваются более подробно.

1.3.4.1 Программный интерфейс приложений ввода-вывода (I/O API)

По сути, этот компонент включает функции диспетчера ввода-вывода, предназначенные для более высоких уровней Windows NT, а также компоненты режима ядра, выполняющие операции, связанные с диспетчером печати. Все имена функций программного интерфейса приложений ввода-вывода имеют вид IoXXXX, где ХХХХ – строка, после которой указывается список параметров. (Подробная информация приводится в программном инструментарии для разработки драйверов.) В качестве примера функций API можно привести:

интерфейс IoCreateDevice, предназначенный для создания новых объектов устройств (объекты устройств рассматриваются в разделе 1.4.2);

интерфейс IoCallDriver, предназначенный для отправки драйверу пакета запроса ввода-вывода (пакеты запроса ввода-вывода рассматриваются в разделе 1.4.3).

1.3.4.2 Диспетчер ввода-вывода (I/O Manager)

Это элемент выполняемого модуля Windows NT; свойственные ему функции перечислены ниже.

Создание пакетов. запроса ввода-вывода (IRP) и направление их соответствующему драйверу, а также перенаправление пакетов запроса ввода-вывода между драйверами.

Удаление и освобождение пакетов запроса ввода-вывода после завершения операции ввода-вывода.

Взаимодействие с диспетчером кэша и другими компонентами NT Executive.

Взаимодействие с диспетчером виртуальной памяти для предоставления файловым системам функций ввода-вывода с записью данных в память.

Мониторинг загруженных файловых систем и их вызов по требованию.

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

Управление буферами для операций ввода-вывода.

1.3.4.3 Драйверы файловых систем

Операционная система предоставляет функции файловых систем с помощью драйверов режима ядра. Система Windows NT поставляется вместе с такими файловыми системами:

NTFS (файловая система NT);

UDFS (универсальная дисковая файловая система);

CDFS (файловая система компакт-дисков);

FAT (таблица размещения файлов).

Драйверы сетевых файловых систем рассматриваются в главе 3. Драйверы файловых систем реализуются средствами инструментария разработки драйверов Windows NT (Windows NT DDK) и дополнительного программного продукта, который предлагается компанией Microsoft – Windows NT Installable File System Kit. Этот инструментарий содержит документацию для различных программных интерфейсов приложений, которые понадобятся при создании драйверов файловой системы, а также пример кода, предназначенного для реализации файловых систем FAT и UDFS.

Драйверы файловой системы аналогичны другим драйверам, поскольку взаимодействуют с диспетчером ввода-вывода и IRP. Драйверы файловой системы являются логическими, так как не взаимодействуют непосредственно с аппаратным обеспечением; например, файловая система не делает различия между дисками с интерфейсом SCSI и с интерфейсом АТА (иногда называемым IDE). Тем не менее драйверы файловой системы отличаются от других драйверов. Некоторые из этих отличий приведены ниже.

Драйверы файловой системы всегда вызываются в контексте потока, запрашивающего операцию ввода-вывода.

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

Драйверы файловой системы являются единственными драйверами, которые обеспечивают работу методов ввода-вывода на основе IRP. Подобный метод называется быстрым вводом-выводом (Fast I/O) и представляет собой несколько входных точек драйвера. Диспетчер ввода-вывода вызывает эти точки для выполнения операций ввода-вывода, поскольку данные могут быть кэшированы и поэтому быстро обработаны. Драйвер файловой системы может завершить вызов неудачно, если это необходимо, а диспетчер ввода-вывода просто повторит тот же запрос ввода- вывода с помощью обычного пакета IRP.

Понятие драйверов фильтров файловых систем тесно связано с понятием драйверов файловых систем. Драйверы фильтрации файловых систем используются для реализации широкого диапазона различных технологий, например шифрованной файловой системы (EFS) и поддержки служб удаленного хранения (RSS).

1.3.4.4 Графическая подсистема

Поскольку эта книга посвящена корпоративным системам хранения данных, на рис. 1.2 графическая подсистема демонстрируется в режиме ядра, хотя некоторая область подсистемы также представлена и в пользовательском режиме. В Windows 2000 для повышения производительности значительный объем кода графической подсистемы был перемещен из пользовательского режима в режим ядра. В данном случае к понятию «графическая подсистема» относится весь программный код, предназначенный для обработки оконного интерфейса и поддерживающий видеоустройства, сканеры, принтеры и т.д.

1.3.4.5 Подсистема Win32

Это наиболее важный компонент Windows NT, особенно для программистов. На основе программного интерфейса Win32 создаются другие подсистемы, такие, как POSIX.

Программный интерфейс приложений Win32 можно разделить на три категории.

1. Обработка оконного интерфейса и API для сообщений оконного интерфейса реализованы в виде динамически подключаемой библиотеки user32. dll. Эта библиотека подключается приложениями, использующими интерфейсы, которые предоставляются этим файлом. При этом несколько приложений во время работы задействуют только одну копию библиотеки.

2. Графический API реализован в виде динамически подключаемой библиотеки gdi32. dll. В версиях Windows NT до Windows 2000 библиотека gdi32. dll являлась клиентом, подключаемым к серверному процессу Win32 (рассматривается далее), так как соответствующие функции были реализованы в серверном процессе. А сервер Win32, в свою очередь, вызывал компонент режима ядра для графической подсистемы. В Windows 2000 библиотека gdi32. dll вызывает этот компонент без посредников.

3. Базовые API, например функции открытия файла (CreateFile), чтения файла (ReadFile) и записи файла (WriteFile), реализованы в динамически подключаемой библиотеке, которая называется ntdll.dll. При необходимости эта библиотека делает вызовы к выполняемому модулю Windows в режиме ядра. Для этого библиотека использует одно из 256 прерываний, поддерживаемых архитектурой Intel х86. В частности, используется прерывание 46 (десятичный номер 46, шестнадцатеричный – 0х2Е). Обработчик прерывания идентифицирует как запрошенный API (выполнив поиск по таблице), так и передаваемые ему параметры. Если все параметры прошли проверку, обработчик вызывает соответствующую подсистему выполняемого модуля Windows для выполнения запрошенной операции.

Приложения, написанные на основе API Win32 и других механизмов поддержки, рассматриваются в документации SDK. В некотором смысле даже подсистема POSIX представляет собой инструмент, разработанный для поддержки приложений UNIX. Хотя подсистема POSIX в настоящий момент существенной роли уже не играет, она все еще служит хорошим примером модульной и расширяемой архитектуры Windows NT.

 

1.4 Структуры данных, связанные с драйверами устройств Windows

Перед подробным рассмотрением драйверов устройств Windows NT стоит разобраться в некоторых важных структурах данных, которые используются этими драйверами. Каждый драйвер Windows, включая драйверы устройств хранения данных, должен взаимодействовать с тремя основными типами объектов: объектами драйверов, объектами устройств и пакетами запроса ввода- вывода (IRP). Эти объекты и рассматриваются в данном разделе.

1.4.1 Объекты драйверов

Объект драйвера создается выполняемым модулем Windows NT при загрузке драйвера. Объект драйвера выделяется из невыгружаемой памяти. Он содержит важную информацию, например таблицу вызовов драйвера, которая, в свою очередь, содержит адреса для различных процедур драйвера. Каждый драйвер, даже если он управляет несколькими устройствами, представлен только одним объектом. Кроме того, когда драйвер обрабатывается несколькими ЦПУ в многопроцессорной системе Windows NT, в памяти присутствует только один объект драйвера. Хотя объект драйвера создается выполняемым модулем Windows NT, обязанность по внесению определенной информации, например адресов процедур в таблицу вызовов драйвера, возлагается на создателя драйвера. Это требование относится только к драйверам, которые экспортируют объект драйвера; таким образом, мини-драйверы, которые зависят от классов или портов объекта драйвера, не обязаны предоставлять описываемую информацию об объекте.

1.4.2 Объекты устройств

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

Три типа объектов устройства имеют одинаковую структуру, однако различаются расширениями и методами использования. Эти объекты описаны ниже.

Объект физического устройства (physical device object – PDO) представляет собой устройство, подключенное к шине и обычно создается драйвером шины (драйверы шины рассматриваются в разделе 1.7.1). Объект физического устройства должен поддерживать связь с устройством. Такой объект должен хранить статус энергопитания устройства и идентификатор устройства, например идентификатор шины SCSI, целевой идентификатор SCSI и номер логической единицы (LUN) SCSI. Эти термины более подробно рассматриваются в главе 2. На данный момент достаточно сказать, что для уникальной идентификации устройства SCSI необходимо указать три значения: идентификатор шины, целевой идентификатор и идентификатор LUN.

Объект функционального устройства (functional device object – FDO) обычно создается драйвером класса или драйвером порта (драйверы классов и портов рассматриваются в разделах 1.7.2 и 1.7.3). Использование устройства требует наличия объекта функционального устройства. В качестве примера данных, которые содержатся в объекте функционального устройства, можно указать элементы архитектуры диска, например таблицу разделов диска или в контексте привода DVD информацию о регионе DVD.

Рис. 1.3. Архитектура объекта устройства Windows NT

3. Объект фильтра устройства (filter device object – DO) представляет собой устройство для драйвера фильтра.

На рис. 1.3 демонстрируются основные структурные элементы объекта драйвера.

К важным элементам объекта драйвера относится таблица вызовов. В ней определены различные стандартные функции, которые реализуются драйвером устройства. В зависимости от конкретной структуры драйвера, некоторые из этих функций должны быть реализованы в обязательном, а некоторые – в произвольном порядке. На рис. 1.3 показаны только функции Read, Write и DeviceIoControl, однако существует и множество других. Для получения дополнительной информации можно обратиться к инструментарию разработки драйверов Windows.

Устройства, функции которых реализуются с помощью драйвера, описываются посредством объектов устройств (PDO, FDO и DO). Все устройства представлены в связном списке. Заголовок связного списка хранится в объек-

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

1.4.3 Пакеты запросов ввода-вывода

Для взаимодействия с драйверами режима ядра многоуровневая операционная система Windows NT использует интерфейсы на основе пакетов данных. Пакеты, которые используются для связи с драйверами, называются пакетами запроса ввода-вывода (I/O request packets – IRP). К драйверу может подключаться другой драйвер или подсистема ввода-вывода.

Пакеты IRP выделяются в невыгружаемой памяти – важнейшем системном ресурсе. Пакеты запроса ввода-вывода выделяются и поддерживаются в очереди, связанной с определенным потоком. Операционная система Windows NT поддерживает готовность к работе некоторого количества пакетов IRP, размещенных в выделенном списке, что позволяет после запроса быстро назначать пакеты драйверу или диспетчеру ввода-вывода.

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

На рис. 1.4 демонстрируется, что заголовок пакета запроса ввода-вывода содержит различные поля данных, перечисленные ниже.

Тип запроса (синхронный или асинхронный).

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

Указатель на буфер для операции ввода-вывода.

Рис. 1.4. Структура пакета запроса ввода-вывода

Статус блока ввода-вывода, который представляет состояние пакета запроса ввода-вывода. Этот статус меняется при обработке пакета различными драйверами.

Информация, необходимая для обработки отмены IRP в случае отмены операции ввода-вывода, указанной в пакете (например, после достижения тайм-аута или по команде пользователя, который решил, что операция выполняется слишком долго).

Указание области возникновения запроса ввода-вывода (в пользовательском режиме или режиме ядра).

Кроме того, на рис. 1.4 показано, что каждый элемент стека содержит информацию, относящуюся к конкретному драйверу. Ниже приведено несколько примеров информации, которая содержится в элементе стека.

Код основной функции (чтение, запись и операция по управлению устройством).

Код вторичной функции, который уточняет необходимое действие и применяется только вместе с соответствующим кодом основной функции.

Параметры функции, например параметры управления устройством.

Указатель на объект файла.

Структура пакета запроса ввода-вывода содержит элемент, указывающий на текущий элемент» стека пакета. Драйвер отвечает за изменение значения этого элемента перед передачей пакета следующему драйверу в цепочке драйверов. Каждый активный пакет запроса ввода-вывода размещается в очереди, связанной с потоком, который содержит пакеты запроса ввода-вывода, связанные с вводом-выводом, запрошенным этим потоком.

В ответ на полученные пакеты драйвер может создавать вторичные пакеты IRP, которые могут обрабатываться одновременно, имитируя параллельную обработку. Это позволяет ускорить обработку ввода-вывода данных. Конечно, в этом случае существуют определенные ограничения: например, операция записи на ленту не может быть разделена на несколько параллельных операций.

 

1.5 Структура драйвера устройства Windows

Все драйверы устройств Windows имеют одинаковую структуру. Каждый драйвер имеет объект драйвера, который создается диспетчером ввода-вывода при загрузке драйвера. В разделе 1.4 представлены структуры данных, которые относятся к драйверам устройств, в том числе и объекты драйверов. В этом разделе описываются процедуры, реализуемые драйвером, а также другие характеристики драйвера устройства хранения данных.

Драйвер устройства Windows реализует множество стандартных процедур, причем некоторые из них обязательны для выполнения, а некоторые – нет, что зависит от свойств драйвера. Ниже перечислены основные стандартные процедуры.

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

• Обязательный набор процедур диспетчеризации для обеспечения работы определенных функций, например чтения, записи, создания и закрытия файлов. Эти процедуры вызываются диспетчером ввода-вывода и получают в качестве параметра пакет запроса ввода-вывода.

• Необязательная процедура запуска (startup routine – StartIO), которая инициирует ввод-вывод данных на физическое устройство. Очевидно, что только драйверы, работающие непосредственно с физическими устройствами (это касается не всех драйверов такого типа), требуют наличия такой процедуры.

• Необязательная процедура обслуживания прерывания (interrupt service routine – ISR). Может использоваться драйверами, взаимодействующими с физическими устройствами. Процедуры обслуживания прерываний рассматриваются в разделе 1.5.1.

• Необязательный отложенный вызов процедуры' (deferred procedure call – DPC), который может использоваться драйвером для дополнительной обработки процедуры обслуживания прерывания. Отложенный вызов процедуры рассматривается в разделе 1.5.2.

• Необязательная процедура завершения, которая вызывается диспетчером ввода-вывода (в качестве механизма уведомления), когда драйвер более низкого уровня завершает обработку пакета запроса ввода-вывода. Поскольку вся операция ввода-вывода обрабатывается в качестве асинхронной, процедура завершения используется довольно часто, особенно в высокоуровневых драйверах, которые всегда обеспечивают обработку пакетов IRP более низкого уровня.

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

• Необязательная процедура отмены (cancellation routine – CancellO), которая вызывается диспетчером ввода-вывода для отмены выполнения длительной операции.

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

• Необязательная процедура протоколирования ошибок.

Обработка пакета запроса ввода-вывода совершается драйвером различными способами, в зависимости от структуры драйвера и запроса ввода-вы- вода в пакете. Ниже приведены некоторые примеры работы драйвера.

• Выполнение запрошенной операции и завершение обработки IRP.

• Выполнение элемента операции и передача IRP драйверу более низкого уровня.

• Обычная передача IRP драйверу более низкого уровня.

• Генерация нескольких пакетов IRP для драйвера более низкого уровня в ответ на получение одного пакета IRP. Например, в ответ на запрос об открытии файла, поступивший от драйвера NTFS, драйверу может потребоваться считать метаданные файла для поиска каталога и подкаталогов, в которых расположен необходимый файл.

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

Обратите внимание, что один и тот же код драйвера может одновременно выполняться на разных центральных процессорах в одной системе Windows NT. Код драйвера должен обладать возможностью синхронизировать доступ к критическим данным кода, выполняемого на разных процессорах. Иногда повторное выполнение одного запроса может стать просто катастрофой, например при записи на магнитную ленту одних и тех же данных повторно.

1.5.1 Процедура обслуживания прерывания

Процедура обслуживания прерывания (interrupt service routine – ISR) обычно выполняется в ответ на получение прерывания от аппаратного устройства и может вытеснять любой код с более низким приоритетом. Процедура обслуживания прерывания должна использовать минимальное количество операций, чтобы центральный процессор имел свободные ресурсы для обслуживания других прерываний. Эта процедура собирает минимум необходимой информации и размещает в очереди вызов отложенной обработки (deffered processing call – DPC) для завершения обслуживания прерывания. Запуск вызова отложенной обработки не планируется на определенное время, т.е. вызов может быть запущен как немедленно, так и немного позднее, в зависимости от необходимости в другой обработке.

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

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

1.5.2 Вызов отложенной обработки

При запуске от процедуры обслуживания прерывания требуется быстрое и эффективное выполнение поставленной задачи. Таким образом, процедура обслуживания прерывания проводит минимум операций и размещает в очереди запрос на вызов отложенной обработки, который используется для завершения оставшихся операций с низким уровнем приоритета (эти уровни обычно называются IRQ или IRQL). Вызов отложенной обработки может быть размещен в очереди не только из процедуры обработки прерывания. Запрос к очереди создает новый объект вызова отложенной обработки (средствами диспетчера объектов). После размещения в очереди создается аппаратный запрос на прерывание (IRQ level 2) для вызова отложенной обработки.

Ниже описаны некоторые важные свойства вызова отложенной обработки.

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

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

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

Вызов отложенной обработки напоминает процедуру обработки прерывания, поскольку также должен выполняться быстро и эффективно. Для минимизации нагрузки на систему при планировании вызовов отложенной обработки Windows NT перед передачей управления DPC сохраняет минимальную информацию о состоянии. После завершения DPC восстановление состояния также занимает мало времени, так как при передаче управления сохранялся минимум информации. В результате DPC может выполняться в контексте произвольного процесса. Например, если программа Excel выполняется в виде процесса и запускает процедуру ввода-вывода, вызов отложенной обработки (если он потребуется) может запускаться в контексте процессов Word или PowerPoint (а не обязательно в контексте процесса Excel).

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

с высоким приоритетом размещается в начало очереди, a DPC с низким и средним приоритетом – в конец очереди.

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

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

Вызов отложенной обработки может быть размещен в очереди другого процессора, если очередь DPC текущего процессора превышает определенное значение. Ядро Windows NT периодически пытается выполнить вызов отложенной обработки, генерируя программные прерывания.

Вызов отложенной обработки не может быть выгружен на диск.

1.5.3 Асинхронный вызов процедуры

Асинхронный вызов процедуры (asynchronous procedure call – АРС) немного похож на вызов отложенной обработки, но существуют и заметные различия. Как и вызов отложенной обработки, АРС выполняется на уровне привилегий, превышающем уровень привилегий обычного кода. В отличие от вызова отложенной обработки, выполняемого в контексте произвольного процесса, асинхронный вызов процедуры всегда выполняется в контексте определенного процесса. Таким образом, асинхронный вызов процедуры требует больших затрат, чем вызов отложенной обработки, так как приходится сохранять и восстанавливать большее количество параметров. Читателю, знакомому с операционными системами UNIX, асинхронные вызовы процедур напомнят процедуры обработки сигналов UNIX.

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

Код пользовательского режима тоже может использовать асинхронный вызов процедур. Для этого необходим прикладной интерфейс программирования QueueUserAPC, который рассматривается в документации к набору Platform SDK. Асинхронные вызовы процедур в пользовательском режиме предоставляются только тогда, когда поток получает предупреждение, например при блокировании в результате вызова функций WaitForSingleObject или WaitForMultipleObject. Подробная информация об этих функциях доступна в документации Platform SDK. Достаточно сказать, что эти функции позволяют организовать синхронизацию потоков.

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

 

1.6 Драйверы и буферы ввода-вывода

В этом разделе рассматриваются буферы ввода-вывода, которые уже упоминались ранее в главе. Драйверы используют буферы для осуществления ввода-вывода и управления им (IOCTL). Для этого драйверы посредством соответствующего объекта указывают предпочтительный способ ввода-вывода. Существует три поддерживаемых драйверами Windows NT типа ввода- вывода: буферизированный, прямой и небуферизированный. Эти методы рассматриваются в данном разделе.

1.6.1 Буферизированный ввод-вывод

Буферизированный ввод-вывод обычно используется для передачи меньших объемов данных, так как в процессе ввода-вывода участвуют операции копирования данных. После того как приложение отправило запрос на ввод- вывод, диспетчер ввода-вывода проверяет соответствие прав доступа приложения к предоставленному буферу ввода-вывода (соответствие прав доступа предполагает, что приложение имеет права на чтение и запись, а также имеет доступ к буферу необходимого размера, указанного в запросе на ввод- вывод). Диспетчер ввода-вывода выделяет буфер в невыгружаемой памяти и в случае запроса на запись копирует данные из буфера приложения в выделенный буфер. Этот буфер передается драйверу.

Драйвер не обязан заботиться о контексте потока, так как буфер находится в невыгружаемой памяти и действителен в контексте любого процесса или потока. Драйвер выполняет необходимую операцию ввода-вывода. Для операции чтения драйвер копирует данные в полученный буфер. Кроме того, драйвер может «предположить», что в контексте виртуального адресного пространства буфер будет непрерывным, но, как и в случае других буферов Windows NT, непрерывность буфера в виртуальном адресном пространстве не гарантирует непрерывности в физическом адресном пространстве.

На этом этапе драйвер завершает обработку IRP, и ответственность за копирование данных из невыгружаемого буфера в буфер приложения возлагается на диспетчер ввода-вывода. Эта операция копирования должна выполняться в контексте процесса, который отправил запрос на ввод-вывод. Кроме того, диспетчер ввода-вывода должен освобождать буфер, выделенный в невыгружаемой области памяти.

1.6.2 Прямой ввод-вывод

Прямой ввод-вывод (Direct I/O) несколько более запутан, чем буферизированный, однако намного эффективнее при выполнении операций ввода- вывода для больших массивов данных. Диспетчер ввода-вывода выполняет базовые проверки, например проверяет разрешения приложения на доступ к буферу посредством области ввода-вывода желательного объема. Буфер в памяти, независимый от процесса, описывается для драйвера средствами структуры данных, которая называется список дескрипторов памяти (memory descriptor list – MDL). Адрес буфера используется в качестве общесистемного виртуального адресного пространства.

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

• блокирование и разблокирование буфера приложения;

• связывание заблокированного буфера с виртуальным адресом, который доступен из контекста любого потока;

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

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

1.6.3 Небуферизированный ввод-вывод

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

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

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

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

 

1.7 Иерархия драйверов систем хранения и типы драйверов

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

В этом разделе представлен обзор стека драйверов устройств хранения Windows NT. Обратите внимание, что речь идет только о базовых, а не обо всех драйверах, связанных с подсистемой хранения данных. Например, драйверы, связанные со службами удаленного хранения (RSS), рассматриваются в главе 7.

На рис. 1.5 демонстрируется стек драйверов подсистемы хранения данных Windows NT. Обратите внимание: здесь представлена многоуровневая архитектура драйверов, однако в зависимости от ситуации те или иные уровни приобретают более важное значение. Ниже приведены примеры подобных ситуаций.

При вводе-выводе данных на физический диск, подключенный через интерфейс IDE или SCSI, необходимы уровни класса и порта, а также уровни файловой системы и управления томами. Все эти уровни рассматриваются далее в главе.

При вводе-выводе данных посредством накопителя на магнитной ленте уровни управления томами и файловой системы не требуются.

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

1.7.1 Драйверы шины

Драйвер шины Windows NT предоставляет функции шины другим драйверам. Термин шина используется в универсальном смысле, обозначая любое виртуальное или физическое устройство, к которому подключаются другие устройства. Драйверы шины необходимы для поддержки процедур перебора, которые вызываются диспетчером Plug and Play для перечисления устройств, подключенных к шине. Кроме того, от драйверов шины требуется предоставление кода обработки РпР, а также пакетов IRP для управления энергопитанием. Компания Microsoft предоставляет драйверы ввода-вывода для всех физических шин персональных компьютеров (например, SCSI, PCI, 1394, USB), хотя независимые поставщики оборудования также могут по мере необходимости предоставлять собственные драйверы шин. Драйвер шины создает объект физического устройства (physical device object – PDO) для каждого устройства, указанного процедурой перечисления устройств.

Рис. 1.5. Стек драйверов хранения Windows NT

1.7.2 Драйверы портов

Драйвер порта реализует специфичные для устройства функциональные возможности и изолирует драйвер класса от влияния особенностей аппаратного обеспечения. Драйвер порта должен реализовать набор указанных функций для драйвера класса и может реализовать дополнительные возможности. Драйвер порта получает пакеты IRP и передает блоки запросов SCSI с встроенными блоками дескрипторов команд драйверу мини-порта, который динамически подключается к драйверу порта. Драйверы мини-портов не создают объектов устройств, а используют созданные драйверами порта. Как отмечалось в разделе 1.4.2, драйверы порта создают объект физического устройства, необходимый для взаимодействия с устройством.

В Windows NT предоставляются некоторые драйверы порта, включая SCSIPort и IEEE 1394. В свою очередь, Windows Server 2003 поставляется

с дополнительным драйвером порта, который называется Storport. На данный момент достаточно сказать, что драйвер SCSIPort используется для работы с устройствами SCSI-2 и более старыми устройствами, а драйвер Storport – с устройствами SCSI-3 и Fibre Channel. Дополнительная информация о драйвере Storport приводится в главе 2.

Драйверы порта, в свою очередь, содержат драйверы мини-портов, которые предоставляются независимыми поставщиками оборудования. Мини- порт обеспечивает функции уровня устройства, которые зависят от конкретного поставщика и не обеспечиваются драйвером порта. Драйверы мини-пор- та создаются с помощью инструментария разработки драйверов Windows NT.

1.7.3 Драйверы классов

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

Создание объекта функционального устройства (FDO). Такой объект необходим для непосредственного использования устройства. В FDO могут содержаться такие данные, как структура организации диска (таблица разделов) или номер региона DVD.

Проверка действительности параметров IRP.

Повторная отправка запросов, обработка которых завершилась неудачно.

В частности, драйверы класса хранения данных выполняют описанные ниже операции.

Разбивка больших запросов чтения/записи (полученных с помощью IRP IRP_MJ_READ и IRP_MJ_WRITE) на меньшие множественные запросы, которые соответствуют возможностям физического адаптера шины.

Получение пакетов IRP и их трансляция в подходящие блоки запросов SCSI (SCSI request blocks – SRB), которые содержат встроенные блоки дескрипторов команд. После этого блоки запросов SCSI отправляются следующему драйверу в цепочке стека, который может оказаться драйвером фильтрации или драйвером порта. Блоки запросов SCSI при этом будут незавершенными, так как драйвер класса не заполняет информацию об адресации в блоке запроса SCSI и в этом зависит от драйвера более низкого уровня.

■ Участие в управлении питанием, добавление и удаление устройств, а также установка тайм-аута для ввода-вывода данных на устройства. Другими словами, драйверы класса устройств хранения активно принимают участие в реализации РпР и управлении энергопитанием.

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

К драйверам класса устройств хранения в Windows NT относятся, например, драйверы дисков, приводов компакт-дисков и накопителей на магнитной ленте; они могут работать с различными устройствами, в том числе подключенными к шинам SCSI, IDE, USB и 1394.

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

Драйверы класса устройства хранения обычно работают аналогично драйверам шины, перечисляя дочерние устройства. Хорошим примером может служить драйвер класса диска (disk. sys), который считывает таблицу разделов диска и создает объекты устройств для каждого найденного дискового раздела.

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

Интересно отметить, что Microsoft добавила в Windows 2000 новую библиотеку, которая называется ClassPnP. Эта библиотека реализует функциональные возможности РпР, общие для всех драйверов класса. При этом некоторые функции полностью реализуются драйвером класса. Для других функций драйвер, который использует библиотеку класса, должен предоставить процедуры обратного вызова, используемые драйвером класса при необходимости. Все драйверы класса, предоставляемые Microsoft (драйверы дисков, накопителей на магнитной ленте и драйверы приводов компакт-дисков), пользуются услугами библиотеки ClassPnP (она реализована в виде файла classpnp. sys). Та же ситуация сохранилась и в Windows XP/Windows Server 2003.

1.7.4 Дерево устройств Windows NT для устройств хранения данных

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

Как уже отмечалось, технология РпР играет вареную роль в идентификации устройств. Интерфейс РпР загружает драйверы шины и инициирует обнаружение устройств, подключенных к этой шине. При обнаружении устройств РпР используется для загрузки соответствующих драйверов. В частности, перечисление устройств начинается с драйвера виртуальной (корневой) шины. Драйвер корневой шины отвечает за перечисление устаревших драйверов DOS и обычно используется для идентификации шин PCI. Драйверы, загруженные драйвером корневой шины, часто называют прошедшими корневое перечисление. К ним относится, например, драйвер шины МРIO (рассматривается в главе 9).

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

На рис. 1.6 в верхнем левом углу иллюстрируется несложная системная конфигурация – сервер Windows NT с одним адаптером шины и одним диском, подключенным к этому адаптеру. Другие периферийные устройства, которые обычно подключены к компьютерам под управлением Windows NT, на рисунке не показаны.

Рис. 1.6. Дерево драйверов устройств

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

Выполняемый модуль Windows NT (в частности, диспетчер РпР) создает объект физического устройства для драйвера шины PCI.

Драйвер шины PCI, в свою очередь, создает объект функционального устройства для шины PCI и подключает его к объекту физического устройства.

Кроме того, драйвер шины PCI идентифицирует (перечисляет) адаптеры и обнаруживает адаптер шины SCSI, после чего создает для него объект физического устройства. Чтобы не усложнять диаграмму на рис. 1.6, другие адаптеры, подключенные к шине PCI, в данный момент не рассматриваются.

Диспетчер РпР загружает драйвер SCSIPort и после инициализации последнего вызывает его через входную точку входа AddDevice. При этом

драйверу в качестве параметра передается объект физического устройства, созданный драйвером шины PCI. Драйвер SCSIPort создает объект функционального устройства для устройства шины. Драйвер порта подключает созданный объект функционального устройства к объекту физического устройства, созданному драйвером шины PCI.

Как уже отмечалось, драйвер может функционировать по-разному, и в данном случае драйвер SCSIPort действует в качестве драйвера шины, перечисляя устройства, которые подключены к шине SCSI. Драйвер обнаруживает диск и сообщает о нем диспетчеру РпР, который загружает драйвер класса диска (disk. sys). После инициализации драйвер класса диска вызывается через входную точку AddDevice и в качестве параметра получает объект физического устройства, который создается драйвером SCSI.

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

Обратите внимание на взаимодействие двух драйверов для создания экземпляров таких логических устройств, как драйвер шины PCI и драйвер SCSIPort. Это вполне логично, так как устройство, с одной стороны, подключается к шине PCI, а с другой – обеспечивает работу интерфейса шины SCSI. Таким образом, одно устройство имеет характеристики как устройства PCI, так и устройства SCSI, поэтому оно должно обрабатываться одновременно драйвером шины PCI и драйвером SCSIPort.

1.7.5 Уровень управления томами

На этом этапе можно вернуться к рис. 1.5 и рассмотреть уровень управления томами. Тома – это логические элементы, которые создаются, чтобы упростить управление устройствами хранения данных. Физические диски, которые подключаются через интерфейсы IDE или SCSI, могут быть логически разбиты на разделы (partitions). Раздел – это физически непрерывный набор секторов диска. Из разделов определенным образом формируется том. Такая комбинация разделов может предоставлять дополнительные возможности: например, несколько разделов могут быть объединены для создания тома, размер которого превышает размер каждого из физических дисков. Еще одним примером может быть создание зеркального тома на основе двух разделов, размер которых совпадает. Дисковые тома рассматриваются более подробно в главе 6. На данном этапе эта тема затрагивается для описания схемы управления томами в Windows NT с помощью драйвера программного устройства.

Рис. 1.7. Дерево объектов устройств для стека томов

В Windows 2000, Windows ХР и Windows Server 2003 поддерживается три различных диспетчера томов: FtDisk, Microsoft Logical Disk Manager и VERITAS Volume Manager. Все они подробно рассматриваются в главе 6. В данном случае в качестве примера будет использоваться базовый диспетчер томов Microsoft FtDisk Manager. Дерево устройств с другими диспетчерами томов также описано в главе 6. Дерево устройств на рис. 1.7 иллюстрирует системную конфигурацию с одним подключенным диском SCSI, содержащим два раздела, которые, в свою очередь, формируют один том.

Для понимания принципов работы диспетчеров томов рассмотрим рис. 1.7, начиная с нижнего правого угла. Подсистема РпР и драйверы шины PCI взаимодействуют для создания объектов физического и функционального устройств для шины PCI. После идентификации устройств, подключенных к шине PCI, драйвер шины PCI создает объект физического устройства для адаптера шины SCSI. Драйвер SCSIPort создает объект функционального устройства для адаптера шины SCSI. Затем драйвер SCSIPort и драйверы класса диска создают объект физического устройства и объект функционального устройства для одного диска, который подключен к шине SCSI. До этого момента на рис. 1.7 вкратце дублировалось содержимое рис. 1.6. -

Диспетчер разделов представляет собой драйвер фильтрации более высокого уровня (драйверы фильтрации рассматриваются в разделе 1.7.7), который регистрируется в подсистеме Windows NT РпР для Получения уведомлений о создании драйвером класса диска новых объектов устройств. Диспетчер разделов появился впервые в Windows 2000 и используется в Windows ХР и Windows Server 2003. Диспетчер разделов взаимодействует с диспетчерами томов (на рис. 1.7 это диспетчер FtDisk) с помощью частных интерфейсов и передает уведомление о создании устройства диспетчеру разделов. Обнаружив все дисковые разделы, которые формируют том, диспетчер тома создает объект устройства, представляющего данный том. Диспетчер разделов обеспечивает уведомление подсистемы РпР относительно удаления объекта устройства или раздела (например, при удалении раздела). Диспетчер разделов связывается с драйвером FtDisk для предоставления последнему информации о динамически добавляемых и удаляемых разделах.

На рис. 1.7, в отличие от предыдущих рисунков, впервые показан диспетчер разделов, который следит за пакетами IRP в процессе ввода-вывода и обеспечивает завершение их обработки. Обнаружив завершение обработки QDR(IRP_MN_QUERY_DEVICE_RELATI0NSHIPS), диспетчер разделов незаметно удаляет дополнительную информацию об обнаруженном устройстве – в данном случае это объект устройства для раздела 0, созданный драйвером класса диска disk. sys. Таким образом объект устройства раздела 0 никогда не обнаруживается подсистемой РпР. Именно поэтому объект устройства для раздела 0 закрашен не так, как все остальные объекты на рис. 1.7.

Диспетчер разделов передает информацию об обнаруженных объектах устройств зарегистрированным диспетчерам томов. На данный момент обсуждение будет ограничено одним диспетчером томов. В главе 6 рассматривается аналогичная ситуация, но уже при участии нескольких диспетчеров томов. Диспетчер томов проверяет устройства, представленные объектами устройств, которые «украдены» диспетчером разделов, и принимает или отвергает владение этими объектами устройств. В этом примере драйвер FtDisk подтверждает свое владение объектами устройств. Затем диспетчер FtDisk проверяет конфигурацию тома и устанавливает, что том сформирован посредством одного раздела, а также определяет владельца соответствующего раздела. На этом этапе драйвер FtDisk создаст объект устройства для тома (на рис. 1.7 он называется «том V01»), после чего можно будет монтировать файловую систему этого тома. Подробности монтирования файловой системы рассматриваются в главе 6.

Следует отметить, что здесь на самом деле рассматриваются два отдельных стека устройств. Один стек представляет логический компонент – том, а второй включает в себя физические устройства системы, например шину PCI, адаптер SCSI и жесткий диск. Диспетчер томов действует как мост между двумя стеками.

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

1.7.6 Драйверы файловой системы

Драйверы файловой системы представляют собой драйверы устройств Windows NT, которые реализуют возможности файловой системы. Хотя файловая система содержится на физическом носителе, например на компакт- диске или жестком диске, драйверы файловой системы рассматриваются в качестве логических, поскольку не используются для непосредственного управления аппаратным обеспечением. Драйверы файловых систем полагаются на драйверы портов и классов для обеспечения ввода-вывода данных на диск и с него. Драйвер файловой системы обычно получает пакет IRP для выполнения запроса и осуществляет одну из двух операций.

Заполняет следующий фрагмент стека пакета IRP необходимой информацией для завершения ввода-вывода. После этого пакет IRP отправляется драйверу класса.

Создает последовательность пакетов IRP для выполнения запрошенного ввода-вывода.

Драйвер файловой системы содержит метаданные на самом носителе. В метаданные входит информация о разрешениях доступа к файловой системе и таблица размещения файлов (расположение файлов на диске). Драйвер файловой системы получает пакет IRP, который указывает на определенную операцию по отношению к файлу, считывает необходимые метаданные и отправляет запрос IRP, который уже относится к блоку диска, а не к файлу. Операционная система поставляется с драйверами файловых систем NTFS, UDFS и FAT.

Создание драйвера файловой системы или драйверов фильтрации для файловых систем в Windows NT З. х; поначалу считали «черной магией». Впоследствии Microsoft предоставила инсталляционный инструментарий файловых систем (Installable File System Kit), который содержит необходимые заголовочные файлы, документацию и примеры создания файловых систем и драйверов фильтрации файловых систем.

Драйверы как файловых систем, так и фильтрации файловых систем должны обеспечивать поддержку пакетов IRP РпР, включая управление питанием, удаление носителя и самого устройства хранения (например, внешнего дисковода на гибких дисках, подключаемого к шине USB).

1.7.7 Драйверы фильтраций

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

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

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

Добавление функциональных возможностей файловой системе, например драйверов фильтрации для шифрования, точек повторной обработки и SIS – Single Instance Storage (рассматривается в главе 6).

Добавление функций шины. Например, в виде поддержки шины AGP или расширений ACPI BIOS.

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

Драйверы фильтрации всегда создают объект устройства, который подключен к объекту функционального устройства или к объекту физического устройства (эти объекты рассматриваются в разделе 1.4.2). Объект устройства необходим драйверу фильтрации для получения пакетов IRP и выполнения предварительной и/или последующей обработки запросов ввода-вывода.

Некоторые драйверы фильтрации создают вторичный объект устройства, который часто называется объектом управляющего устройства (control device object – CDO), так как он используется для отправки управляющей информации драйверу фильтрации с помощью соответствующего модуля управления. Драйверы фильтрации, которые подключаются к объекту функционального устройства, созданному драйвером класса, называются драйверами фильтрации верхнего уровня. В свою очередь, драйверы фильтрации, которые подключаются к объекту физического устройства, размещенному ниже в стеке и созданному драйвером порта, называются драйверами фильтрации нижнего уровня.

Драйверы фильтрации нижнего уровня отличаются более сложной структурой, чем драйверы верхнего уровня. К одной из технических проблем относится выбор сообщаемых ошибок,, а также операций ввода-вывода, ошибки которых сообщаются. Еще одна проблема – отсутствие готовых примеров драйверов нижнего уровня, поскольку все доступные примеры описывают драйверы верхнего уровня. Иногда (достаточно редко) драйверы нижнего уровня предоставляют функции протокольного преобразователя или функции, позволяющие обойти некоторые ограничения в работе аппаратного устройства.

Драйверы фильтрации существовали в Windows NT с момента появления ее первой коммерческой версии. Пакет Windows NT Installable File System Kit () представляет собой неплохой справочник для разработчиков, в котором подробно документируется архитектура драйверов фильтрации.

Начиная с Windows 2000, в процесс загрузки драйверов фильтрации были внесены значительные изменения. Ранее дополнительная работа по проверке правильности загрузки драйвера ложилась на плечи создателя драйвера. Если драйвер загружался слишком рано, объект устройства, к которому должен подключиться драйвер, мог еще не существовать. Если драйвер загружался слишком поздно, устройство могло оказаться занятым другим драйвером; это приводило к тому, что драйвер фильтрации в стеке драйверов помещался выше, чем было необходимо. В Windows 2000 создатель драйвера указывает размещение драйвера выше или ниже определенного объекта физического устройства или объекта функционального устройства, а диспетчер Plug and Play загружает драйвер в подходящее время.

Похоже* что компания Microsoft чересчур упростила процесс создания драйвера фильтрации. Цепь стека драйверов стала чрезмерно «переполненной», что подразумевает проблемы с производительностью и загрузкой памяти (каждый пакет IRP должен содержать больше фрагментов стека, а пакеты IRP размещаются в невыгружаемой памяти). Достаточно посмотреть на список драйверов фильтрации, которые загружаются в операционной системе:

драйвер фильтрации шифрованной файловой системы;

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

драйвер фильтрации SIS для служб удаленной установки (RIS);

драйверы фильтрации для точек повторной обработки от сторонних поставщиков;

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

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

 

1.8 Ввод-вывод типичного приложения хранения данных

Теперь соберем вместе все описываемые концепции и тщательным образом рассмотрим типичное приложение хранения данных. Это позволит разобраться с различными компонентами Windows NT, которые описывались ранее в главе, а также понять принципы их использования.

Рассматриваемое нами приложение будет просто считывать данные из файла. Файл размещен на томе, который управляется диспетчером томов FtDisk. Поскольку эта конфигурация идентична конфигурации, показанной на рис. 1.7, дерево объектов устройств не изменится. На рис. 1.8 представлена упрощенная версия дерева объектов устройств с рис. 1.7. Чтобы уменьшить объем предлагаемой информации, взаимодействие файловой системы с диспетчером кэша во внимание не принимается, т.е. предполагается, что файл не кэшируется.

Ниже описаны операции, которые приводятся на рис. 1.8.

Приложение, например резервного копирования, выдает запрос на чтение. 'После ряда стандартных проверок подсистема ввода-вывода перенаправляет запрос с помощью пакета IRP соответствующей файловой системе.

Файловая система определяет, что ей необходимо получить данные тома. Драйвер файловой системы создает пакет IRP с необходимыми параметрами, включая смещение в пределах тома, где должна быть выполнена операция чтения, и объем операции чтения. Кроме того, драйвер файловой системы указывает процедуру завершения ввода-вывода. После этого драйвер файловой системы отправляет пакет IRP диспетчеру томов.

Рис. 1.8. Операция чтения на томе

Диспетчер томов преобразует значение смещения тома в значение смещения на диске и заполняет соответствующий пакет IRP. Затем средствами диспетчера ввода-вывода пакет IRP отправляется драйверу класса диска.

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

Драйвер SCSIPort размещает пакет IRP в очереди, запрашивая некоторые операции у драйвера мини-порта, который управляет адаптером SCSI. На этом этапе пакет IRP отмечается как ожидающий выполнения и отправляется назад. Обычно диспетчер ввода-вывода обрабатывает пакет IRP в порядке, обратном только что описанному, т.е. после драйвера порта следует драйвер класса, затем диспетчер томов, а за ним файловая система. На каждом этапе пакет IRP отмечается как ожидающий выполнения. На определенном этапе ввод-вывод будет отправлен на физическое устройство средствами шины PCI.

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

Запускается процедура обслуживания прерывания, которая помещает в очереди вызов отложенной обработки для завершения обработки вво- да-вывода. После запуска вызова отложенной обработки драйвер SCSI- Port отмечает пакет IRP как завершенный и вызывает диспетчер ввода- вывода для дальнейшей обработки пакета. Диспетчер ввода-вывода обрабатывает пакет запроса ввода-вывода и вызывает процедуру завершения следующего драйвера в цепочке стека, т.е. драйвера класса диска.

Диспетчер ввода-вывода вызывает процедуру завершения драйвера класса диска. Процедура завершения выполняет необходимые операции обслуживания и вызывает диспетчер ввода-вывода для дальнейшей обработки пакета IRP. Диспетчер ввода-вывода переносит обработку на один уровень выше в цепочке стека драйверов. В данном случае к драйверу диспетчера томов FtDisk.

Вызывается процедура завершения драйвера FtDisk, которая выполняет собственную обработку. После завершения обработки вызывается диспетчер ввода-вывода, которому сообщается о завершении обработки пакета IRP. Диспетчер ввода-вывода переходит вверх по стеку и вызывает процедуру завершения следующего драйвера – драйвера файловой системы.

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

 

1.9 Сложности практической реализации

Стек ввода-вывода подсистемы хранения в семействе Windows Server описан в этой главе довольно подробно. Но помните, что стек подсистемы хранения не обслуживает устройства, поддерживающие несколько протоколов.

Чтобы повысить надежность и безопасность операционной системы Windows, компания Microsoft расширяет и улучшает методику сертификации и подписи драйверов. Поставщикам рекомендуется сертифицировать все обновления драйверов. Хорошим источником информации по этому вопросу может служить Web-узел компании Microsoft, в частности Web-страница по адресу: .

 

Резюме

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

Драйвер фильтрации позволяет добавить новые функции для Windows NT. Компания Microsoft использовала подобный драйвер при создании приложения Hierarchical Storage Management.

В целом создание драйверов Windows NT требует серьезных знаний в этой области и доступа к подходящему программному инструментарию.