Нет, ну это понятно. А как же тогда пишутся фильтры для последовательных портов? Например, PortMon. Он одновременно общается и со своим юзер-може приложением, и одновременно дает открыть lower level драйвер ком-порта обычным приложениям. Ок. Я все же попробую, что получится — скажу.

Спасибо!

V>По хорошему фильтры должны брать флаги нижележащих устройств (ну и модифицировать их по необходимости). Но здесь все равно имеется логическая проблема. Даже если ты уберешь флаг экслюзивности у устройства, какое-нить приложение может создать хэндл сериал порта для эксклюзивного доступа (передать 0 в dwShareMode при CreateFile), поэтому неприемлемо иметь устройство для общения с твоим приложением, сидящее наверху стека самого сериалпорта (если только действительно нужна работа этого приложения одновременно с другими, пользующимися портом)

AS>>А если использовать IoAttachDevice для вторичного девайса вместо IoAttachDeviceToDeviceStack?
AS>>Тут то экслюзивность сохраняется?
V>Эксклюзивность задается при IoCreateDevice (флаг bExclusive) или позже, через DEVICE_OBJECT::Flags (DO_EXCLUSIVE)

AS>>И можно ли после этого убить SourceDevice (см. IoAttachDevice), или они должны жить вместе с AttachedDevice долго и умереть в один день?
V>Какже ты его убъешь??? Ты ж его только что приаттачил сверху на стек???

AS>>А оверхед... В принципе, всего 2 варианта:
AS>>1. Для каждого девайса — свой саттелит. При этом в DEVICE_EXTENSION саттелита хранится lower device настоящего девайса. Соотв, надо различать, запрос к чему идет. Можно для это цели выбрать первый элемент структуры в DEVICE_EXTENSION, который будет указывать, саттелит это или нет. Соотв., дальнейшие поля DEVICE_EXTENSION в зависимости от этого интерпретируются по-разному.
AS>>2. Для всех девайсов — один саттелит. При этом при первом вызове из юзер-моде приложения ему возвращается соотв. DEVICE_OBJECT настоящего девайса, который потом и используется при вызовах для роутинга между настоящими девайсами.

AS>>Для метода (2) наверное, каждый запрос к драйверу требует нового IRP. Или нет?
AS>>Очевидно, что для (1) все может быть проще — просто передаем запрос ниже по стеку драйверов и все.
AS>>Правда, если только насчет эксклюзивности ты ошибся

AS>>Мне просто интересно не как логичнее на мой взгляд, а как делают другие, т.к. у меня опыта пока немного и все кажется весьма сложным.
V>Ну все зависит от логики работы этого "вторичного" устройства. Если логично и удобно чтоб он был один, надо делать один. Если нужно много — можно сделать много, на "оверхед" можно не обращать внимания. Если сообщищь, что собирается делать приложение, можно чтонить поконкретнее сказать =)

AS>>И еще. А почему рекомендуешь создавать пул IRP заранее (под пулом подразумевается LinkedList?)? Чем это удобно? Почему нельзя создавать IRP непосредственно при необходимости, в момент запроса?
V>Вообще-то это неудобно =) Но если нет гарантий, что dispatchentry будет вызвана при PASSIVE_LEVEL — это необходимо.
V>Если ты уверен, что будет PASSIVE_LEVEL (например если все запросы к твоему устройству идут от тебя же), можешь создавать новый ирп прям в момент запроса.