Здравствуйте, block_head, Вы писали:

_>Разрабатывается TDI — фильтр, который при любой сетевой активности должен спросить у юзер-мод приложения — разрешить или нет. Вопрос следующий — как правильно организовать ожидание ответа от приложения в драйвере. Как я понимаю есть два способа — объявить irp как pending или поместить в очередь.

Это в принципе, одно и тоже. Просто речь идет о том, что Вы можете поддерживать очередь отложенных IRP в своем драйвере или оставить это на откуп системе. Вам придется поддерживать собственную очередь ( это не обязательно будет именно очередь — это может быть список, массив, хоть хеш таблица ). Дело в том, что Вам необходимо обрабатывать IRP в ответ на реакцию пользователя — т.е самостоятельно извлекать нужный пакет IRP из какого то хранилища, причем скорее всего это не будет FIFO очередь. Разработчики драйверов устройств часто сталкиваются с ситуацией, когда устройство элементарно занято и нужно накапливать запросы в FIFO очереди. Для этого частого случая ОС имеет поддержку таких очередей. Чтобы воспользоваться этим сервисом, драйвер имеет специальную точку входа, заданную в DRIVER_OBJECT — StartIo, а система предоставляет функции IoStartPacket и IoStartNextPacket для управления этой очередью. В любом случае, диспетчерский обработчик, отложивший обработку IRP должен вернуть STATUS_PENDING и отметить IRP как отложенное ( IoMarkIrpPending ).

Если говорить про TDI — не всякий запрос может быть безопасно отложен. Например драйвер netbt.sys может неправильно вести при получении статуса STATUS_PENDING на некоторые типы запросов, которые он предполагал будут выполнены синхронно.