Курсовая работа: Протоколирование обмена информацией между компьютером и внешним запоминающим USB-устройством
Поле UrbHeader хранит информацию о коде URB‑пакета, по которому можно определить, какая операция запрашивается.
Поля UrbSelectInterface и UrbSelectConfiguration служат для запроса по выбору интерфейса и конфигурации устройства, которые будут использоваться при работе с устройством. Пакеты этой структуры отправляются хостом к устройству в начале его работы, при конфигурировании.
Поле UrbBulkOrInterruptTransfer несет наиболее важную в рамках данной курсовой работы информацию – указатели на блоки ввода / вывода USB‑устройства. Приведемописаниеструктуры_URB_BULK_OR_INTERRUPT_TRANSFER:
struct _URB_BULK_OR_INTERRUPT_TRANSFER {
struct _URB_HEADER Hdr;
USBD_PIPE_HANDLE PipeHandle;
ULONG TransferFlags;
ULONG TransferBufferLength;
PVOID TransferBuffer;
PMDLTransferBufferMDL;};
Поля этой структуры описаны в следующей таблице:
Таблица 1.5.3 Поляструктуры URB_BULK_OR_INTERRUPT_TRANSFER
| Поле | Описание |
| struct _URB_HEADER Hdr | Стандартный заголовок URB‑пакета, содержащий код запроса |
| USBD_PIPE_HANDLE PipeHandle | Дескриптор канала, на который передаются данные |
| ULONG TransferFlags | Флаги, определяющие направление передачи данных и способ обработки ошибок |
| ULONG TransferBufferLength | Длина передаваемого блока данных в байтах |
| PVOID TransferBuffer | Указатель на передаваемый буфер. Буфер находится в нестраничной памяти |
| PMDL TransferBufferMDL | Указатель на MDL‑список, несущий передаваемую информацию. Буфер находится в страничной памяти |
Следует отметить, что один из указателей TransferBuffer или TransferBufferMDL равен NULL, то есть в пределах одного пакета передается только одна порция данных.
Задача протоколирования обмена информацией сводится к перехвату и сохранению буферов TransferBuffer и TransferBufferMDL.
1.6 Уровни запроса прерываний
В каждый момент времени центральный процессор находится на одном из уровней IRQL (InterruptRequestLevel– уровень запросов прерываний). Уровни IRQL располагаются в порядке убывания от HIGHEST_LEVEL до PASSIVE_LEVEL. Каждому из прерываний (прерывания от внешних устройств, системные часы, и т.д.) соответствует свой уровень IRQL. Специальным действиям операционной системы также назначены IRQL. Они отмечены в нижней части приведённой таблицы:
Таблица 1.6.1. Уровни запросов прерываний.
| Уровень | Назначение |
| HIGHEST_LEVEL | Наивысший уровень. Все прерывания заблокированы |
| POWER_LEVEL | Прерывания по отказу питания |
| IPI_LEVEL | Межпроцессорное взаимодействие |
| CLOCK2_LEVEL | Прерывание по системному таймеру 2 |
| СLOCK1_LEVEL | Прерывание по системному таймеру 1 |
| PROFILE_LEVEL | Прерывание по таймеру замера производительности |
| уровни DRQL | Обычные прерывания устройств |
| DISPATCH_LEVEL | Диспетчеризация потоков и выполнение отложенных процедур |
| APC_LEVEL | Выполнение асинхронного вызова процедуры |
| PASSIVE_LEVEL | Обычное исполнение кода потока |
Общее правило обработки уровней запросов прерываний гласит, что прерывания с IRQL, меньшим, чем у выполняемого в данный момент кода, маскируются. Во время исполнения кода потока (пользовательского или системного) устанавливается наименьший IRQL = 0 (PASSIVE_LEVEL). Работа драйвера чаще всего выполняется на уровне IRQL = 2 (DISPATCH_LEVEL). Уровни, лежащие над ним, называются DIRQL (DeviceIRQL) и выставляются для обработчиков прерываний от внешних устройств (ISR– interruptserviceroutine). Даже во время выполнения ISR драйвера может произойти прерывание с большим IRQL, например, принадлежащее другому драйверу.
Чем выше текущий уровень IRQL исполняемого кода, тем меньше функций ему доступно. Так, например, диспетчер потоков работает на уровне
DISPATCH_LEVEL, и, следовательно, не будет вызываться, пока на процессоре с уровнем большим или равным DISPATCH_LEVEL исполняется другой код. Таким образом, на уровнях DISPATCH_LEVEL и выше отключается переключение потоков. Функции ожидания диспетчерских объектов (события, мьютексы, семафоры) с отличным от нуля временем, обращение к файлам, подкачка отсутствующих в физической памяти страниц – всё это также становится недоступным. Для корректного сохранения запросов в файле фильтр в таких случаях должен применять специальную методику.
1.7 Уведомление о завершении запроса нижестоящим драйвером
При отслеживании обмена данными драйвер-фильтр может получать уведомления о том, что некоторый переданный запрос был завершён нижестоящим драйвером. Механизм уведомления заключается в том, что вызовом специальной функции IoSetCompletionRoutine фильтр обращается к стеку в пакете IRP. В позиции стека, следующей за текущей позицией, он устанавливает в специальном поле адрес функции завершения (completionroutine). Затем при передаче пакета по цепочке позиция стека увеличивается.
Когда нижестоящий драйвер отправляет пакет запроса на завершение (вызовом IoCompleteRequest ), подсистема ввода / вывода начинает просматривать стек внутри этого пакета от конца к началу. Если в какой-то позиции стека определена функция завершения, управление передаётся ей. Отработав, функция возвращает результат, сигнализирующий об успехе, ошибке или необходимости дальнейшей обработки запроса.
При первых двух вариантах подсистема ввода / вывода переходит к следующей позиции стека и продолжает просмотр, пока не будет достигнуто его начало. После этого запрос завершается нормальным образом.
При третьем же варианте просмотр стека немедленно прекращается и запрос не будет завершён. Эта возможность реализована для того, чтобы драйвер-фильтр мог выполнить какие-либо действия над пакетом запроса после того, как тот будет обработан в нижестоящем драйвере. После такой «дополнительной обработки» пакет снова