Кто — нибудь их писал, у кого есть их примеры и какие ограничения есть для такого вида драйверов ?
Могут ли быть tightly coupled drivers не для PnP драйверов ?

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

E>Кто — нибудь их писал, у кого есть их примеры и какие ограничения есть для такого вида драйверов ?
E>Могут ли быть tightly coupled drivers не для PnP драйверов ?
в наших проектах последние 4 года обычно работает связка из 2-х tightly coupled drivers:
первый драйвер — настоящий file system filter driver
второй драйвер — функциональный драйвер реализующий собственно всю логику, клиент 1го драйвера

на фильтре лежат стандартные задачи: приаттачиться везде где нужно, следить за всем чем нужно (EX: mount events) и предоставить в конечном счете удобный для использования функциональным драйвером сервис:
— конструирование и кэш имен файлов
— подсчет ссылок на file objects
— правильно вызвать все IRP_MJ_XXX + FastIoXxx Pre & Post handlers.

При инициализации функдрайвера он регистрируется у первого драйвера и указывает на какие именно события он желает отвечать: например CreatePre & ClosePost (до вызова IoCallDriver в IRP_MJ_CREATE и после в IRP_MJ_CLOSE).

Соотв. задача написания нового фильтра сильно упрощается — можно сосредоточиться только на бизнес-логике и меньше отвлекаться на такие трудоемкие "мелочи" как конструирование имени файла в CreatePreHandler (до реального открытия файла фильтр УЖЕ вызывает обработчик функционального драйвера, если он есть, с ГОТОВЫМ именем файла)

соотв и не нужно каждый раз тратить время на bugfixing & QA фильтра — все это экономит на каждом новом фильтре "с нуля" около 6-9 мес труда разработчика (при использовании нашей среды с такой моделью)

кстати FDDK от OSR выполнено по схожему принципу — связка из нескольких драйверов...

но и написание такого универсального фильтра — задача далеко нетривиальная, на наш фильтр люди потратили 3 года еще до меня, а сейчас следующая версия выходит и продукту уже более 5 лет вложенных сюда точно получается

если нужна ссылка, то смотрите The File System Filter Framework for Windows, это первая версия продукта (выпущен довольно давно но по работает без проблем и на XР и на 2003 — есть даже бинарная совместимость начиная с НТ4). Скоро начнется рекламная компания второй версии, в разработке которой я уже принимал участие

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

V>если нужна ссылка, то смотрите The File System Filter Framework for Windows, это первая версия продукта (выпущен довольно давно но по работает без проблем и на XР и на 2003 — есть даже бинарная совместимость начиная с НТ4). Скоро начнется рекламная компания второй версии, в разработке которой я уже принимал участие

Возможно посмотреть скелет такого драйвера ?

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

E>Возможно посмотреть скелет такого драйвера ?
я думаю что в инете Вы найдете подобные примеры (наверняка на OSR что-то должно быть в разделе NT Insider)

однако ничего сложного тут нет: Вам нужно всего лишь добиться загрузки обоих драйверов в память, затем фильтр посылает зарегистрированному драйверу-клиенту приватный IOCTL с таблицей ф-ий обратного вызова, в ответ на который функциональный драйвер сообщает что именно он желает обслуживать.

кстати, я не уверен что именно такой механизм Вы имели ввиду под tightly coupled drivers, ведь еще есть Kernel mode DLL (aka Export drivers: see Creating Export Drivers in the MSDN/DDK/IFS). У нас же скорее multi-tier driver architecture — модель без жесткой привязки даже по имени DLL — функциональный драйвер регистрируется через реестр у фильтра, а тот в свою очередь при загрузке с помощью ZwLoadDriver подгружает его (если он сам еще не поднят) и далее по схеме выше — IOCTL.

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

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

E>>Возможно посмотреть скелет такого драйвера ?
V>я думаю что в инете Вы найдете подобные примеры (наверняка на OSR что-то должно быть в разделе NT Insider)

V>однако ничего сложного тут нет: Вам нужно всего лишь добиться загрузки обоих драйверов в память,

То есть они грузятся независимо друг от друга и порядок загрузки не имеет никакого значения ?



Посмотрите, пожалуйста почту.
Смотрел в книге Jerry Lozano небольшой параграф, в котором описывались эти драйвера, там речь шла об интерфейсах.
То есть находится GUID фильтруемого драйвера и затем фильтр отправляет функциональному драйверу IRP_MJ_PNP и IRP_MN_QUERY_INTERFACE для получения нужного интерфейса.
Вроде так.

То есть " затем фильтр посылает зарегистрированному драйверу-клиенту приватный IOCTL с таблицей ф-ий обратного вызова, в ответ на который функциональный драйвер сообщает что именно он желает обслуживать. " и то, что написано в книге Lozano, так понимаю не совсем одно и тоже ?



V>кстати, я не уверен что именно такой механизм Вы имели ввиду под tightly coupled drivers, ведь еще есть Kernel mode DLL (aka Export drivers: see Creating Export Drivers in the MSDN/DDK/IFS). У нас же скорее multi-tier driver architecture — модель без жесткой привязки даже по имени DLL — функциональный драйвер регистрируется через реестр у фильтра, а тот в свою очередь при загрузке с помощью ZwLoadDriver подгружает его (если он сам еще не поднят) и далее по схеме выше — IOCTL.

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

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

E>>Возможно посмотреть скелет такого драйвера ?
V>я думаю что в инете Вы найдете подобные примеры (наверняка на OSR что-то должно быть в разделе NT Insider)

V>однако ничего сложного тут нет: Вам нужно всего лишь добиться загрузки обоих драйверов в память, затем фильтр посылает зарегистрированному драйверу-клиенту приватный IOCTL с таблицей ф-ий обратного вызова, в ответ на который функциональный драйвер сообщает что именно он желает обслуживать.

V>кстати, я не уверен что именно такой механизм Вы имели ввиду под tightly coupled drivers, ведь еще есть Kernel mode DLL (aka Export drivers: see Creating Export Drivers in the MSDN/DDK/IFS).
Это мне не подойдет.
Есть драйвер A, которому приходят пакеты от другого драйвера (драйвера В).
Не подойдет Export drivers потому, что драйвер A, которому tightly coupled driver предполагает подсовывать что — то "свое" для отправки драйверу B или смотреть что приходит драйверу A или что уходит от него написан не мной.
То есть прилинковать kernel — mode dll к драйверу не получиться.

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

E>Кто — нибудь их писал, у кого есть их примеры и какие ограничения есть для такого вида драйверов ?
E>Могут ли быть tightly coupled drivers не для PnP драйверов ?

КСТАТИ, может будет полезно:
Beyond IRPs: Driver to Driver Communications
Methods for Driver – Driver Communication

E>Это мне не подойдет.
E>Есть драйвер A, которому приходят пакеты от другого драйвера (драйвера В).
чем не нравится IoAttachDeviceXxx?

V>>однако ничего сложного тут нет: Вам нужно всего лишь добиться загрузки обоих драйверов в память,
E>То есть они грузятся независимо друг от друга и порядок загрузки не имеет никакого значения ?
нет, фильтр при загрузке смотрит, есть ли уже нужный драйвер (точнее его Device Object) в памяти и если нет, то подгружает. Ну и соединяетя с ним в обоих случаях следом (отправляет IOCTL).

Посмотрите, пожалуйста почту.
E>Смотрел в книге Jerry Lozano небольшой параграф, в котором описывались эти драйвера, там речь шла об интерфейсах.
к сожалению незнакомый мне автор, просветите что за источник?

E>То есть находится GUID фильтруемого драйвера и затем фильтр отправляет функциональному драйверу IRP_MJ_PNP и IRP_MN_QUERY_INTERFACE для получения нужного интерфейса.
E>Вроде так.
судя по описанию похожая схема. Просто file system drivers вообще говоря не PnP драйвера (но моугт часть ф-ий поддерживать)

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

E>>Это мне не подойдет.
E>>Есть драйвер A, которому приходят пакеты от другого драйвера (драйвера В).
V>чем не нравится IoAttachDeviceXxx?
Во — первых медленне, чем общение драйверов не через I/o manager, во — вторых, изначально не известно, кто еще сидит на стеке (может уже какой — то драйвер есть, например монитор) .

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

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

E>>Кто — нибудь их писал, у кого есть их примеры и какие ограничения есть для такого вида драйверов ?
E>>Могут ли быть tightly coupled drivers не для PnP драйверов ?

V>КСТАТИ, может будет полезно:
V>Beyond IRPs: Driver to Driver Communications
V>Methods for Driver – Driver Communication
Спасибо. Гляну.
Но все таких хотелось бы посмотреть ещё примеры или услышать способы "общения драйверов" напрямую, минуя manager, при условии, что нет исходников фильтруемого драйвера.
Например у того же Lozano чего — то там описано, но мало и написано вроде про PnP устройства.
Есть даже рисунок (про указатели на функции) .

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

E>Но все таких хотелось бы посмотреть ещё примеры или услышать способы "общения драйверов" напрямую, минуя manager, при условии, что нет исходников фильтруемого драйвера.
--
В одном из наших проектов стояла задача снимать с платы А, которая управлялась приложением А через свой драйвер А, кое-какую информацию (управление платой осуществялось через личные IOCTL коды, значения которых были доступны). Эта информация снималась PCI-картой В, которая физически подключалась к плате А и имела свое приложение В и свой драйвер В. Для того, чтобы не трогать приложение А вообще, было решено написать device-фильтр BF, который находился над драйвером А и следил за IOCTL кодами, приходящими к нему, и в нужный момент времени запускал процессы в плате В через ее драйвер В.

Приложение В сканировало все драйвера в системе и находила все драйвера А. Пользователь выбирал тот драйвер (и, соответственно, ту плату), за которым нужно было следить. Имя этого драйвера передавалось в драйвер В, который создавал device-фильтр BF и подсоединял его как верхний фильтр к драйверу А. При создании device'а BF ему передавался указатель на драйвер В (все было написано на С++ и передавался указатель на абстрактный объект, реализующий интерфейс к драйверу В, в конструкторе объекта BF), который в BF запоминался. Затем, при "проходе" нужных IOCTL через device BF, последний вызывал виртуальный метод по указателю на интерфес к В, в реализации которого и осуществлялось управление платой В.

Такая схема работы успешно работала как под windows NT4, так и под XP.

C уважением,
Геннадий Майко.

Здравствуйте, Геннадий Майко, Вы писали:

ГМ>Здравствуйте, Exkurs, Вы писали:

E>>Но все таких хотелось бы посмотреть ещё примеры или услышать способы "общения драйверов" напрямую, минуя manager, при условии, что нет исходников фильтруемого драйвера.
ГМ>--
ГМ>В одном из наших проектов стояла задача снимать с платы А, которая управлялась приложением А через свой драйвер А, кое-какую информацию (управление платой осуществялось через личные IOCTL коды, значения которых были доступны). Эта информация снималась PCI-картой В, которая физически подключалась к плате А и имела свое приложение В и свой драйвер В. Для того, чтобы не трогать приложение А вообще, было решено написать device-фильтр BF, который находился над драйвером А и следил за IOCTL кодами, приходящими к нему, и в нужный момент времени запускал процессы в плате В через ее драйвер В.

ГМ>Приложение В сканировало все драйвера в системе и находила все драйвера А. Пользователь выбирал тот драйвер (и, соответственно, ту плату), за которым нужно было следить. Имя этого драйвера передавалось в драйвер В, который создавал device-фильтр BF и подсоединял его как верхний фильтр к драйверу А. При создании device'а BF ему передавался указатель на драйвер В (все было написано на С++ и передавался указатель на абстрактный объект, реализующий интерфейс к драйверу В, в конструкторе объекта BF), который в BF запоминался. Затем, при "проходе" нужных IOCTL через device BF, последний вызывал виртуальный метод по указателю на интерфес к В, в реализации которого и осуществлялось управление платой В.

ГМ>Такая схема работы успешно работала как под windows NT4, так и под XP.

ГМ>C уважением,
ГМ>Геннадий Майко.
Драйвер BF был реализован посредством IoAttachXXX или иным способом ?

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

ГМ>>Такая схема работы успешно работала как под windows NT4, так и под XP.

ГМ>>C уважением,
ГМ>>Геннадий Майко.
E>Драйвер BF был реализован посредством IoAttachXXX или иным способом ?
--
Device BF создавался как обычно, вместе с device'ом В (в DriverEntry). Затем, при приходе IOCTL вызова из приложения В, уже существующий device BF подключался к device'у А с использованием функции IoAttachDevice.
Device B так же имел указатель на абстрактный базовый объект интерфейса device BF и мог им так же управлять — в частности, отключал его в от device'a A в нужные моменты времени.

Маленькое уточнение — то, что система работала и под XP, не означает, увы, что драйвера были PNP.

С уважением,
Геннадий Майко.

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

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

E>>>Это мне не подойдет.
E>>>Есть драйвер A, которому приходят пакеты от другого драйвера (драйвера В).
V>>чем не нравится IoAttachDeviceXxx?
E>Во — первых медленне, чем общение драйверов не через I/o manager, во — вторых, изначально не известно, кто еще сидит на стеке (может уже какой — то драйвер есть, например монитор) .
ну и пуская сидит — значит так надо
его задача ничего не испортить либо быть как настоящий драйвер — Вас это мало должно по идее парить без особых на то причин ИМХО

Здравствуйте, Геннадий Майко, Вы писали:

ГМ>Здравствуйте, Exkurs, Вы писали:

ГМ>>>Такая схема работы успешно работала как под windows NT4, так и под XP.

ГМ>>>C уважением,
ГМ>>>Геннадий Майко.
E>>Драйвер BF был реализован посредством IoAttachXXX или иным способом ?
ГМ>--
ГМ>Device BF создавался как обычно, вместе с device'ом В (в DriverEntry). Затем, при приходе IOCTL вызова из приложения В, уже существующий device BF подключался к device'у А с использованием функции IoAttachDevice.
ГМ>Device B так же имел указатель на абстрактный базовый объект интерфейса device BF и мог им так же управлять — в частности, отключал его в от device'a A в нужные моменты времени.

ГМ>Маленькое уточнение — то, что система работала и под XP, не означает, увы, что драйвера были PNP.

ГМ>С уважением,
ГМ>Геннадий Майко.

Пытаюсь понять, возможно ли написать что — то вроде драйвера фильтра для драйвера, исходный код которого не известен, чтобы эти 2 драйвера "общались" минуя I/O manager (или сведя общение через I/O manager к миниму, например на этапе посылки фильтром каких — либо управляющих команд фильтруемому драйверу ) .

возможно конечно, вся система так устроена и пока все довольны

а отчего так IO Manager то Вас смущает, он тут причем?
если Вы перехватили в драйвере А что-то у драйвера Б то отправляя пакет дальше через IoCallDriver Вы естественно минуете Io Manager...

E>Пытаюсь понять, возможно ли написать что — то вроде драйвера фильтра для драйвера, исходный код которого не известен, чтобы эти 2 драйвера "общались" минуя I/O manager (или сведя общение через I/O manager к миниму, например на этапе посылки фильтром каких — либо управляющих команд фильтруемому драйверу ) .

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

V>возможно конечно, вся система так устроена и пока все довольны


V>а отчего так IO Manager то Вас смущает, он тут причем?
Дак вот прочитал Lozano, пишет, что вот эти tightly couplde drivers, работающие без I/O manager' a, работают быстрее там мала вероятность оказывания фильтра в стеке, где — нибудь далеко от фильтруемого драйвера.
V>если Вы перехватили в драйвере А что-то у драйвера Б то отправляя пакет дальше через IoCallDriver Вы естественно минуете Io Manager...

E>>Пытаюсь понять, возможно ли написать что — то вроде драйвера фильтра для драйвера, исходный код которого не известен, чтобы эти 2 драйвера "общались" минуя I/O manager (или сведя общение через I/O manager к миниму, например на этапе посылки фильтром каких — либо управляющих команд фильтруемому драйверу ) .

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


E>Пытаюсь понять, возможно ли написать что — то вроде драйвера фильтра для драйвера, исходный код которого не известен, чтобы эти 2 драйвера "общались" минуя I/O manager (или сведя общение через I/O manager к миниму, например на этапе посылки фильтром каких — либо управляющих команд фильтруемому драйверу ) .
--
Если "нижний" device поддерживает vendor-supplied интерфейс к себе (см. IRP_MN_QUERY_INTERFACE), то можно попытаться использовать его напрямую, в обход I/O manager'a.

С уважением,
Геннадий Майко.

Здравствуйте, Геннадий Майко, Вы писали:

ГМ>Здравствуйте, Exkurs, Вы писали:


E>>Пытаюсь понять, возможно ли написать что — то вроде драйвера фильтра для драйвера, исходный код которого не известен, чтобы эти 2 драйвера "общались" минуя I/O manager (или сведя общение через I/O manager к миниму, например на этапе посылки фильтром каких — либо управляющих команд фильтруемому драйверу ) .
ГМ>--
ГМ>Если "нижний" device поддерживает vendor-supplied интерфейс к себе (см. IRP_MN_QUERY_INTERFACE), то можно попытаться использовать его напрямую, в обход I/O manager'a.

ГМ>С уважением,
ГМ>Геннадий Майко.
Для получения этого интерфейса от "нижнего" драйвера, нужно будет вызвать IoCallDriver с запросом к нижнему драйверу, поддерживает он этот интерфейс или нет ?