Далее процедура вызывает истинный диспетчер прерываний, копируя в стек вызова информацию из объекта. Если IRQL не разделяемый, то происходит установка на процессоре IRQL с помощью специальной функции ядра системы и непосредственный вызов ISR драйвера.
Обобщенная схема обработки аппаратного прерывания.
Если же IRQL является разделяемым, то происходит опрос ISR драйверов, соответствующих вызванному объекту прерывания, пока один из драйверов не уведомит, что это им обслуживаемое устройство ожидает обработки запроса.
Теперь начинается так называемая критичная часть выполнения драйвера. Процесс обработки прерывания драйвером происходит в два этапа: этап ISR (критичный по времени) и этап DPC (Deferred Procedure Call, о котором будет сказано далее). ISR выполняет небольшой подготовительный процесс, и ставит в системную очередь процессора запрос на выполнение некритичной части драйвера (его DPC процедуры).
Следует пояснить термин «DPC». DPC - это одновременно и уровень IRQL на котором выполняются DPC-процедуры, поставленные в очередь, и системный механизм выполнения таких процедур. Механизм заключается в том, что для каждого процессора существует своя специальная очередь выполнения кода - DPC очередь. Как только уровень IRQL понижается до DPC (находится ниже всех уровней устройств, но выше уровня выполнения пользовательских кодовых потоков), система проверяет эту очередь на наличие в ней запросов. Если таковые имеются, происходит их поочередная обработка.
Схема обработки DPCочереди.
Процедура DPC драйвера производит более объёмную работу, например, в отношении сетевых карт, передачу ответа на запрос из сети. Порой основной и единственной задачей ISR драйверов является постановка DPC процедуры драйвера в очередь DPC.
Вернёмся к нашему эксперименту. После того, как DPC драйвера выполнила свою работу, она передаёт её результаты одному из диспетчеров, в нашем случае - специальному системному модулю - диспетчеру ввода-вывода. Передача происходит через интерфейсную функцию, экспортируемую этим модулем.
Дальнейший процесс уже можно предугадать - передача серверу подсистемы - передача ожидающей нажатия клавиши функции (а она всегда имеется, если система в одной из внутренних процедур не зациклилась и не вошла в клинч). После этого процедура обработки сообщений, например, поля ввода (системный класс окон «EDIT») произведёт вырисовку символа на экране в клиентской области своего окна.
Заключение.
Мы проследили лишь гипотетический путь развития событий. Это лишь иллюстрация. Это значит, что не всё происходит в точности, как описано. Можно достоверно сказать только то, как происходит обработка типичного аппаратного прерывания в Windows.
В завершении этого доклада хотелось бы указать не освещённые стороны вопроса о прерываниях. Прерывания можно генерировать и программно. Например, пользовательский код для выполнения какой-либо функции исполнительной системы, код которой доступен только из режима ядра, вызывает специальное сервисное прерывание, после чего кодовый поток продолжает своё выполнение уже в режиме ядра. Прерывания может генерировать и сам процессор для самоконтроля, отладки исполняемого кода, либо при ошибках во время выполнения кода (run-time). Ошибки выполнения, приводящие к прерываниям, называются исключениями (например: деление на ноль, неверный код операции, выход при контроле значения за границы).
В заключении хотелось бы отметить то, что весь этот довольно сложный процесс происходит незаметно от пользователя. Собственно он так и должен работать - как только пользователь нажал клавишу, он хочет видеть результат своих действий на экране.
Список использованной литературы
1. Внутреннее устройство Microsoft Windows: Windows Server 2003, Windows XP и Windows 2000. M. Pуссинович, Д. Соломон, Изд. «Питер» 2005, Лиц. «MicrosoftPress»
2. “Windows Sys Tales”-Adequatus Project-2006. mailto:buffovich@mail.ru
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.