Основы организации и работы подсистемы ввода-вывода windows
Взаимодействие компонентов операционной системы Windows, вовлеченных в обслуживание задач ввода-вывода, схематично показано на рис. .14.
Как и в UNIX, приложения пользовательского режима Windows получают доступ к устройствам ввода-вывода через файловый интерфейс, открывая файлы, ссылающиеся на устройства, по их именам с использованием системного вызова CreateFile. Имена псевдофайлов, ассоциированных с устройствами, располагаются в адресном пространстве диспетчера имен, которое обозначается префиксом “\\.\” перед именем файла. (В программе на языке C имя указывается как “\\\\.\\каталог\\имя”). Имена псевдофайлов, сопоставленных с устройствами, создаются в адресном пространстве диспетчера имен драйверами, обычно, посредством вызова функции диспетчера ввода-вывода IoCreateSymbolicLink.
Рис.14. Взаимодействие компонентов подсистемы ввода-вывода Windows
Получив описатель файла, программа пользовательского режима может обратиться к устройству посредством системных вызовов WriteFile, ReadFile или DeviceIoControl.
Вызовы перечисленных функций транслируются подсистемой Win32 в вызовы недокументированных функций истинного интерфейса ntdll.dll, в котором происходит генерация командного прерывания и переключение в режим ядра.
Обработка командного прерывания, связанного с системными вызовами, выполняется диспетчером системных вызовов. Диспетчер системных вызовов копирует параметры системного вызова из стека вызывающего потока в стек ядра и вызывает функцию диспетчера ввода-вывода по адресу, хранящемуся в таблице диспетчеризации, используя в качестве индекса таблицы номер системного вызова, занесенный функцией недокументированного интерфейса в регистр процессора перед генерацией командного прерывания (на платформе x86 используется регистр eax).
Заметим, что описываемые действия все еще выполняются в контексте того процесса, поток которого инициировал запрос на ввод-вывод. Поэтому функция диспетчера ввода-вывода обращается к таблице описателей объекта, чтобы по описателю файла получить адрес объекта файл исполнительной системы. Как будет показано далее, через объект файл диспетчер ввода-вывода находит соответствующий драйвер. После чего диспетчер ввода-вывода вызывает соответствующую функцию соответствующего драйвера.
Данная функция драйвера будет выполнена в контексте процесса, поток которого инициировал запрос на ввод-вывод. Это позволяет драйверу, при необходимости, получить доступ к данным, даже если они размещены а пользовательской части адресного пространства процесса. Если драйвер может немедленно завершить запрошенную операцию, он выполняет необходимые действия и сигнализирует диспетчеру ввода-вывода о завершении операции. Диспетчер ввода-вывода завершает прерывание и управление возвращается в функцию недокументированного интерфейса, из нее в функцию документированного интерфейса, функция WriteFile, ReadFile или DeviceIoControl завершается и пользовательская программа продолжает работу.
Если драйвер не может выполнить запрос немедленно, например, ему необходимо выполнить обращение к контролируемому устройству, он все равно завершает функцию, вызванную диспетчером ввода-вывода в контексте исходного процесса, но при этом указывает незавершенный статус запроса (STATUS_PENDING). Это приводит к переключению контекста на другой процесс, готовый к выполнению.
После завершения обработки запроса драйвером, например, при генерации прерывания по завершению ввода-вывода, драйвер информирует диспетчер ввода-вывода о завершении отложенного запроса. Но поскольку теперь диспетчер ввода-вывода выполняется в контексте случайного процесса, а не того процесса, который послал запрос ввода-вывода, если для завершения обработки запроса требуется передача данных пользовательскому приложению, обычно используется APC (исключение составляет прямой ввод-вывод, когда пользовательский и системный буфер настроены на работу с разделяемой памятью, и копирование данных в пользовательское пространство не требуется).
В процессе выполнения запроса драйвер может обращаться к системному реестру и к функциям интерфейса режима ядра для получения услуг операционной системы: выделение памяти, доступ к объектам, синхронизация, таймеры и т.п.
Для доступа к регистрам внешнего устройства, драйвер опирается на поддержку функций уровня абстрагирования от аппаратуры – HAL.