1. Существуют ли способы обойти ограничения на размер передаваемого UM буфера для DIRECT_IO девайсов? /дабы избежать двойного буфера, повторного мэппинга, 64Мб ограничения для mdl и т.п. но быть под крылом i/o манагера (для верхнего драйвера) в остальных вопросах.../ Как заставить манагер создавать ассоциативные mdl, а не один? /т.е. подключить поле struct _MDL *Next; или это совсем не сработает?/ 3. На что влияют параметры открытия устройства /FILE_FLAG_NO_BUFFERING напр., другие/, если все параметры указываются во флагах самого объекта устройства при создании? Или они для внутреннего пользования конкретных девайсов, которые создают ещё одни вторичные буферы? 2. Все ли верхлежащие драйверы начинают обработку irp'ов в контестке потока-инициатора запроса? Где можно посмотреть список кодов mj и mn запросов которые выполняются синхронно и асинхронно для всех слоёв? Грубо говоря, все irp запросы выполняются в верхлежащем драйвере синхронно? и асинхронность на совести самих слоёв? 3. Существуют ли ещё более продвинутые аналоги WinObjEx? с различн. доп. ф-ями по типу дампить ядерную память представленных структур и сопутствующих указателей в них? Дампить irp обработчики (хотябы ту страницу куда ссылаемся)? Кстати WinObjEx показывает хуки обработчиков поставленные непосредственно заменой адреса в DRIVER_OBJECT или есть анализ на сплайс первых байт обработчиков?
Four-F оперативно и подробно)) Спасибо! reactos "дизассемблилась" с какой версии выни кто-нить знает?
n0name Во-во, тоже заметил, что код довольно актуален и очень похож на актуальную правду в бинарном виде (на ядро в последних его ипостасях)
Вопросы актуальны. про >64MiB юзермодный буфер: неужели решается только через neither (buffered не подходит) и mdl в цикле?
