Доброго времени суток! разрабатываю драйвер для устройства PCI используя masm32 и KmdKit. Драйвер не WDM. (пока что не WDM)) Все процедуры инициализации провожу в DriverEntry. По каталогу объектов \Device нахожу свой PDO и присоединяюсь к его стеку с помощью IoAttachDeviceToDeviceStack. Все вроде бы выглядит нормально и в DeviceTree видно что мое FDO стало в нужный стек устройств. Но.. во первых ... IoAttachDeviceToDeviceStack меняет флаги в (DEVOBJ_EXTENSION PTR [eax]).ExtensionFlags (eax - указывает на DEVOBJ_EXTENSION) причем так, что в результате из пользовательского приложения нельзя открыть символическую ссылку на устройство (ошибка GetLastError 2 - файл не найден). После IoAttachDeviceToDeviceStack сбрасываю принудительно эти флаги в прежнее состояние. Пользовательское приложение начинает получать хендл устройства с помощью CreateFile на символическую ссылку. Прочитать конфигурацию моего устройства можно только получив интерфейс шины BUS_INTERFACE_STANDARD через IRP_MJ_PNP IRP_MN_QUERY_INTERFACE. В DDK есть ссылка на функцию IoInvalidateDeviceState. Если ее вызывать то PNP менеджер должен по идее послать мне PNP пакет в драйвер IRP_MN_QUERY_PNP_DEVICE_STATE. А я там устанавливая в PNP_DEVICE_STATE флаг PNP_DEVICE_RESOURCE_REQUIREMENTS_CHANGED должен каким то образом уведомить PNP менеджер о том что мне нужен новый список ресурсов? Здесь начинается путаница в голове)))) Я что то совсем не так понял??? То что я объявил у себя в драйвере хендл на IRP_MJ_PNP не означает что PNP менеджер считает мое Fdo полностью соответствующим устройству на стек которого я присоединился ??? Или нельзя вызывать в DriverEntry IoInvalidateDeviceState??? Из - за какого то флага во флагах моего Fdo или PDO, к которому я приаттачился? Да - важная деталь. Мое PDO не имеет никаких промежуточных драйверов фильтров и изначально создается драйвером шины PCI для устройства которому не назначен драйвер по реестру. А я подключаюсь к нему описанным выше нестандартным сопсобом. Может быть потому что я не провел стандартную процедуру инициализации через реестр и inf файл PNP менеджер не признает моего FDO полноценным ?? впрочем я уже повторяюсь ))) заранее признателен всем кто что то может подсказать!
А зачем ставить Visual Studio и DDK ??))))) Я проработал на Visual Studio 9 лет (пишу это чтобы не было недопонимания)) У меня вопрос по существу.))) Что необходимо и достаточно для того чтобы PNP менеджер посчитал мой драйвер вместе с PDO достойными своего драгоценного внимания? И второй вопрос чем плох ассемблер ??????????! Чем?
Во-первых, только PnP менеджер решает какой драйвер нужен для девайса и когда его грузить. Для этого он должен быть соответствующим образом установлен через inf файл. Минимально должно быть реализовано: * Функция AddDevice. * Обработчик IRP_MJ_PNP. Как минимум обработка всех так называемых State Transition PnP IRPs. IRP_MN_START_DEVICE IRP_MN_QUERY_REMOVE_DEVICE IRP_MN_REMOVE_DEVICE IRP_MN_CANCEL_REMOVE_DEVICE IRP_MN_STOP_DEVICE IRP_MN_QUERY_STOP_DEVICE IRP_MN_CANCEL_STOP_DEVICE IRP_MN_SURPRISE_REMOVAL * Обработчик IRP_MJ_POWER. * Обработчик IRP_MJ_SYSTEM_CONTROL. Если нужна связь с юзером то ссылка регистрируется через создание интерфейса IoRegisterDeviceInterface. Настоятельно рекомендую взять семпл DDK\src\general\toaster и доку Toaster Sample Drivers in the Driver Development Kit. В тостере есть примеры всего стека: Дравер шины, драйвер FDO, все варианты фильтров. Примеры юзерных приложений. Примеры инсталеров. Причем драйвер FDO в четырех вариантах от минимального до полнофункционального. Не рекомендую юзать masm32/KmdKit ибо даже минимальный PnP драйвер - это уже достаточно сложная конструкция. Просто потратишь времени раз в 10 больше. К тому же в KmdKit нет поддержки PnP.
Спасибо! Насчет KmdKit вы правы я детально просмотрел включаемые файлы. Важных структур и описаний функций там нет некоторых. Впрочем это как раз можно сделать хотя и будет определенная трата времени. Пример toaster ОБЯЗАТЕЛЬНО посмотрю более внимательно. Бегло уже кое что смотрел. Если я правильно понял Вас то без установки драйвера через inf файл PNP менеджер не производит некоторые инсталляционные процедуры для PDO моего устройства в стеке и не связывает с ним определенную информацию в своей базе. Поэтому если я нелегальным способом получаю его адрес через каталог объектов присоединяю некоторое FDO к его стеку то это еще не означает что PNP считает его в рабочем состоянии ? По поводу реализации функций Wdm AddDevice есть но она понятное дело не вызывается в таком варианте установки. Обработчик минор - кодов IRP_MJ_PNP сейчас мне важен прежде всего чтобы убедиться что сообщения пошли от PNP менеджера. Вот IRP_MJ_POWER и IRP_MJ_SYSTEM_CONTROL не реализовывал. Быть может и в этом еще есть проблема. Спасибо еще раз за информацию!
IRP_MJ_POWER и IRP_MJ_SYSTEM_CONTROL должны быть. IRP_MJ_SYSTEM_CONTROL может ничего не делать, но должен форвардить IRP вниз по стеку. IRP_MJ_POWER очень простой. Насчёт inf... это по сути скрипт, который в минимальном варианте делает несколько записей в реестр и копирует файл драйвера в системный каталог если надо. Нужен только на этапе первичной инсталляции драйвера. Если всё то же самое сделать руками, то теоретически разницы никакой. Насчет "PNP считает его в рабочем состоянии" хз. Точно сказать не могу, но думаю, что если реализовать необходимый минимум обработчиков и сделать всё правильно должно заработать. Хотя возможно что по выходу из AddDevice драйвера система заполняет какие-то структуры использующиеся PnP менеджером. Этого я не знаю. Однако советую не парить себе мозг. По любому разрабатывать драйвер реального устройства PCI на асме - это мазохизм. Хотя если Вы делаете это исключительно из-за любви к искусству, то нормально. Если же результат важнее процесса, то перейти с асма на чистый си довольно легко. Это займет наверное даже меньше времени, чем процесс прикручивания legacy драйвера к PnP стеку. Один день можно потратить на прочтения вводных глав из какой-нибудь книги по си и на разбор исходника DDK\src\general\toaster\func\incomplete1. Второй на эксперименты. Третий на переваривание усвоенного. Дальше будет проще. А так Вы просто будете головой об стену... с непредсказуемым результатом.
Я понимаю ваше мнение. Моя задача облегчается тем что на си и на си++ я писал много лет от программ 3д графики до распределенных систем на основе COM DCOM это не хвастовства ради а просто чтобы прояснить ситуацию. Более того несколько лет назад с помощь драйвер студио пришлось быстро наваять драйвер для обращения по TCP/IP из режима ядра чтобы сохранить концепцию распред. вычислений при возникновении в нашем проекте нового класса устройств. Так что вполне можно считать что делаю это на асме из любви как к асму так и к искусству в целом) Думаю даже что как только разберусь перепишу все уже с инф файлом и с нормальной инсталляцией. Просто сейчас еще ситуация в том что нежелательно пока что ходить к разработчикам устройства за лишней информацией ))) В любом случае спасибо Вам! буду копаться пока не припечет как войн дзэна)
Уважаемый Four-F ! еще раз спасибо за рекомендации я посмотрел внимательно более Toaster! Затем получил список ресурсов моего девайса с помощью GetDevice...Property (написал в программе и забыл к вечеру))). Реализовал у себя и IRP_MJ_SYSTEM_CONTROL и IRP_MJ_POWER. Более тщательный анализ функции IoAttachDeviceToDeviceStack дал то что она ставит мне в расширенные флаги флаг из моего PDO то есть из DEVOBJ_EXTENSION.ExtendedFlags под значением 10h. Анализируя код функции IoAttachDeviceToDeviceStack в Вашем же цикле про драйверы режима ядра и код ее же в дизассемблере понял что это флаг DOE_START_PENDING. За что дополнительно огромное спасибо! Затем нелегкая заставила меня залезть в дизассемблер функции IoInvalidateDEviceState и вот что я там обнаружил. Перед запуском внутренней процедуры идет проверка во первых на флаг устройства, затем проверяется поле DeviceNode в структуре DEVOBJ_EXTENSION при равенстве которого нулю переход на BugCheck. А затем идет ссылка относительно DeviceNode на какие то внутренние поля с двумя смещениями (сейчас под рукой нет дизассемблера и как то из головы цифры вылетели((). Там идет строгая проверка на равенство одного поля 2 а другого 308h. При первом неравенстве - BugCheck при втором просто выход без выполнения внутренней процедуры уведомления менеджера PNP об изменении состояния. Вопрос вот в чем, структура, на которую ссылается поле DeviceNode где - нибудь была исследована ??? Или это та черта за которой уже лучше ничего не искать и уж тем более не править вручную?))) Просто у меня руки чесались поподключаться к разным устройствам на моем компе и проверить это поле) а потом просто для моего устройства его выправить ) Опять же ради чистого искусства и лучшего понимания работы системы и PNP менеджера)
Маладец. А теперь сходи и открой для себя исходники ядра Windows Server 2003 SP1, которые можно скачать "почти" в открытом доступе.
Есть три возможности глянуть на исходники внутренностей винды. 1. ReactOS - опенсорсный клон Windows с точностью до имён функций. Абсолютно свободно и бесплатно. http://www.reactos.org/ru/download.html 2. Windows Research Kernel. При определённых условиях можно слить у самой m$. Или поискать в сети. http://www.microsoft.com/resources/sharedsource/windowsacademic/researchkernelkit.mspx Это то, про что x64 сказал постом выше. 3. Утекшие в 2004 году исходники Windows NT4 и 2000. На torrents.ru точно есть.
Благодарю за информацию! Утекшие исходники заботливо лежать уже давно в библиотеке как раз в 2004 году).. но я в них почему то не заглянул)) И самое главное) Я все же поставил значение 308h в то злосчастное поле и свершилось чудо))) Все сообщения пошли как будто так и должно быть) А потом я заглянул в информацию об устройстве и о чудо) Оказалось что на вкладке сведения если выбрать флаги DevNode появятся интересные флаги которые говорят о том что устройтво дескать уже стало иметь драйвер. Так что с большой долей вероятности можно предположить что те два поля из дизассемблера функции как раз эти самые флаги) Может кому будет полезно...) Всем спасибо за помощь!
