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

U>Непосредственно образ диска полностью абстрактный — я просто форварджу все IO в user-mode, где их обрабатывает один из динамически подключаемых плагинов.
Я тоже.

U>Насколько я понял, покопавшись еще немного в этой теме, получив от bus'а PDO для очередного замонтированного диска, мне достаточно создать такой FDO, к которому PnP подключит сверху storage class driver (disk.sys).
Неверно. Ваша забота — создать PDO для вашего диска. И только (в смысле — никаких других DO не нужно).
U>Где-то еще выше станет PartitionManager. Соответственно, disk.sys начнет выполнять всю грязную работу по распознаванию партишенов, посылая моему девайсу некоторые IOCTL (вроде GET_DISK_GEOMETRY, но не GET_DRIVE_LAYOUT), и пачку запросов на чтение (я так понимаю, уже в виде SRB, а не как IRP). Соответственно, моей основной заботой с этого момента станет обработка read/write. Поправьте меня, плиз, если я где-то в этой общей схеме не прав.
Остальное верно. Можно добавить только, что SRB тоже приходят как IRP (IRP_MJ_SCSI aka IRP_MJ_INTERNAL_DEVICE_CONTROL).
U>В общем, теперь возникает вопрос, как собственно заставить PnP manager'а прицепить ко мне наверх disk.sys. Просмотр msdn пока ничего не дает на эту тему. Этот момент (именно касательно disk.sys, или в виде какого-то шаблона, из которого можно вывести мой случай) вообще где-то документирован?
А что именно вас интересует "именно касательно disk.sys". В обсуждаемом отношении у него нет никакой специфики.

U>Все, что я пока нашел, это один пост на osronline, из которого я понял, что мой PDO должен иметь некий специфический HardwareId (GenDisk вроде бы).
Один только? Дайте ссылку, пожалуйста.
U>А подключаемый в стек новый девайс должен иметь тип MASS_STORAGE
Вообще-то, все это делается так:
1. Создаем PDO:

    status = IoCreateDevice(FdoData->Self->DriverObject,
                sizeof (PDO_DEVICE_DATA),
                NULL,
                FILE_DEVICE_MASS_STORAGE,
                FILE_AUTOGENERATED_DEVICE_NAME |FILE_DEVICE_SECURE_OPEN,
                FALSE,
                &pdo);
    if (!NT_SUCCESS (status))
    {
        return status;
    }

    pdoData = (PPDO_DEVICE_DATA) pdo->DeviceExtension;

    //
    // Copy the hardware IDs
    //

    pdoData->HardwareIDs =
            ExAllocatePoolWithTag (NonPagedPool, BUS_HARDWARE_IDS_LENGTH, BUSENUM_POOL_TAG);

    if (NULL == pdoData->HardwareIDs) {
        IoDeleteDevice(pdo);
        return STATUS_INSUFFICIENT_RESOURCES;
    }

    RtlCopyMemory (pdoData->HardwareIDs, BUS_HARDWARE_IDS, BUS_HARDWARE_IDS_LENGTH);
    pdoData->SerialNo = AddDisk->handle;
    status = Bus_InitializePdo (pdo, FdoData, AddDisk);
    if (!NT_SUCCESS (status))
    {
        return status;
    }

    //
    // Device Relation changes if a new pdo is created. So let
    // the PNP system now about that. This forces it to send bunch of pnp
    // queries and cause the function driver to be loaded.
    //

    IoInvalidateDeviceRelations (FdoData->UnderlyingPDO, BusRelations);

То есть, вызываем IoCreateDevice, а затем IoInvalidateDeviceRelations. В ответ на IoInvalidateDeviceRelations ваш драйвер получит кучу запросов IRP_MJ_PNP, в частности, IRP_MN_QUERY_ID. Именно в ответ на этот запрос вы должны выдать DeviceID и прочее. На основе этой информации система найдет драйвер для FDO. Вам нужно сформировать такие IDы, чтобы этим драйвером оказался disk.sys, то есть, попросту говоря, чтобы система подумала, что это у вас диск. По этому поводу см. Identifiers for SCSI Devices (это ссылка на локально установленный WDK 6000). Поэтому,
2. Обрабатывем IRP_MN_QUERY_ID:

    switch (stack->Parameters.QueryId.IdType) {

    case BusQueryDeviceID:
///////////////
        break;

    case BusQueryInstanceID:
///////////////
        break;


    case BusQueryHardwareIDs:
///////////////
        break;


    case BusQueryCompatibleIDs:
///////////////
        break;

    default:

        status = Irp->IoStatus.Status;

    }

(у меня этот код целиком взят из toaster, так что тексты обработчиков выбросил для ясности). Единственное, что я изменил, это строки, возвращаемые драйвером, потому что нужно, чтобы это был не тостер, а диск.

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

E>Что зачем? Кто будет обрабатывать все запросы от Partition Manager? disk.sys этого не делает.
А что это за запросы? partmgr это просто вехний фильтр диска, который мониторит изменения в таблице разделов, с тем чтобы вовремя нотифицировать pnp о создании/удалении раздела.

E>Он пересылает IOCTL запросы на драйвер лежащий ниже в стеке.
драйвер, лежащий ниже в стеке — это scsi(stor)-port. Касательно ioctl, котрые он должен обрабатывать см. ntddscsi.h

E>Reference: WDK\src\storage\class\disk\
кстати, в WDK тяжело читать disk.sys, т.к. его функциональность теперь несколько размазана. Чисто в образовательных целях я бы рекомендовал изучать по исходникам из c:\WINDDK\3790.1830\src\storage\class\disk\

Здравствуйте,

Имеется работающий legacy virtual disk driver, который умеет монтировать образ диска, лежащий в файле. В текущем виде драйвер практически всю работу делает сам ручками: при монтировании диска сам сканит MBR (IoReadPartitionTable), детектит партишены и создает девайсы для каждого из вольюмов.

Появилась необходимость поддержать образы, содержащие dynamic disk. И вот тут мы имеем грабли: драйвер видит все 4 simple volumes, находящихся на сэмпловом dynamic disk'е, но размеры всех, кроме первого, равны нулю.

Есть следующие идеи по доработке драйвера, выглядящие одинаково рисково:

1) Остаться в рамках legacy driver, и попытаться выяснить, какой набор IOCTL или еще чего-то нужно дообработать. Тут есть также идея как-то используя IoRegisterDeviceInterface заставить систему сделать всю работу по распознаванию и монтированию содержимого диска. Хотя, IoRegisterDeviceInterface требует на вход PDO, который не совсем понятно, откуда брать, и это, думаю, только вершина айсберга проблем

2) Полностью переписать драйвер в виде virtual SCSI miniport. Тут, судя по тому, что я нарыл в OSRONLINE есть некоторые неприятные грабли (например, SRB completion), обходящиеся различными хаками. Но в целом этот путь выглядит как вполне органичное решение, практически неминуемо приводящее к счастью

Вопрос в том, какой из путей является чуть менее рисковым
Прежде написанием SCSI miniport'ов заниматься не приходилось, и достойных примеров в DDK найти не удалось, но достижение результата при этом варианте выглядит более реальным.
С другой стороны, есть вероятность, что дописав немного кода к текущему драйверу можно также добиться желаемого, но уже с гораздо более туманными перспективами.

Помогите, пожалуйста, сделать правильный выбор!

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

U>Здравствуйте,

U>Имеется работающий legacy virtual disk driver, который умеет монтировать образ диска, лежащий в файле. В текущем виде драйвер практически всю работу делает сам ручками: при монтировании диска сам сканит MBR (IoReadPartitionTable), детектит партишены и создает девайсы для каждого из вольюмов.

U>Появилась необходимость поддержать образы, содержащие dynamic disk. И вот тут мы имеем грабли: драйвер видит все 4 simple volumes, находящихся на сэмпловом dynamic disk'е, но размеры всех, кроме первого, равны нулю.

U>Есть следующие идеи по доработке драйвера, выглядящие одинаково рисково:

U>1) Остаться в рамках legacy driver, и попытаться выяснить, какой набор IOCTL или еще чего-то нужно дообработать. Тут есть также идея как-то используя IoRegisterDeviceInterface заставить систему сделать всю работу по распознаванию и монтированию содержимого диска. Хотя, IoRegisterDeviceInterface требует на вход PDO, который не совсем понятно, откуда брать, и это, думаю, только вершина айсберга проблем
Самое правильное решение. И никаких проблем.

U>2) Полностью переписать драйвер в виде virtual SCSI miniport. Тут, судя по тому, что я нарыл в OSRONLINE есть некоторые неприятные грабли (например, SRB completion), обходящиеся различными хаками. Но в целом этот путь выглядит как вполне органичное решение, практически неминуемо приводящее к счастью
Ну и неправда ваша. Не выйдет.

U>Вопрос в том, какой из путей является чуть менее рисковым
U>Прежде написанием SCSI miniport'ов заниматься не приходилось, и достойных примеров в DDK найти не удалось, но достижение результата при этом варианте выглядит более реальным.
Самый главный пример — это bus из комплекта toaster.
U>С другой стороны, есть вероятность, что дописав немного кода к текущему драйверу можно также добиться желаемого, но уже с гораздо более туманными перспективами.

U>Помогите, пожалуйста, сделать правильный выбор!

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

В динамическом диске структура диска храниться не в mbr, а в специальной области в конце диска.
Структура достаточно сложная и связанна с операционной системой.

Если вы будете использовать scsi минипорт то база данных динамического диска прочитаеться но он будет foreihn и его нужно будет импортировать в систему. при этом данные в базе данных изменяться и в самой оси тоже.
Соответсвенно если парсить бд ldm то это очень непросто. пример парса есть в исходниках линукс.

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

U>Есть следующие идеи по доработке драйвера, выглядящие одинаково рисково:

U>1) Остаться в рамках legacy driver, и попытаться выяснить, какой набор IOCTL или еще чего-то нужно дообработать. Тут есть также идея как-то используя IoRegisterDeviceInterface заставить систему сделать всю работу по распознаванию и монтированию содержимого диска. Хотя, IoRegisterDeviceInterface требует на вход PDO, который не совсем понятно, откуда брать, и это, думаю, только вершина айсберга проблем

PDO получают на входе AddDevice.Вы должны создать object драйвера через bus driver. Тип object — FILE_CONTROLLER.

Спасибо всем за информацию.
Насколько я понял, задачка все-таки проще решается без полного переписывания драйвера в качестве SCSI miniport (и это не может не радовать, так как при виде обсуждений virtual SCSI miniport на osronline становится грустно ).

Существуют как минимум 2 варианта решения в рамках текущего драйвера:
1. Дополнительно распарсить структуру динамического диска, и создать все партишены руками, как происходить сейчас. Вариант, как я вижу, сильно непростой и рисковый.
2. Используя IoRegisterDeviceInterface + GUID_DEVINTERFACE_DISK зарегистрироваться в системе как диск, и обработать все IOCTL от MountManager'а + IOCTL_SCSI. Тогда код по созданию партишенов выбрасывается, но появляется еще 1 драйвер — bus driver для возможности динамически монтировать/демонтировать диски.

Еще раз спасибо за направление. Ушел изучать toaster

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

U>2. Используя IoRegisterDeviceInterface + GUID_DEVINTERFACE_DISK зарегистрироваться в системе как диск, и обработать все IOCTL от MountManager'а + IOCTL_SCSI.
Это не нужно. Пусть этим занимается disk.sys. Ваша забота — PDO предоставлять и обрабатывать некоторые IOCTLы и IRP_MJ_SCSI.
U>Еще раз спасибо за направление. Ушел изучать toaster
Это правильно.

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

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

U>>2. Используя IoRegisterDeviceInterface + GUID_DEVINTERFACE_DISK зарегистрироваться в системе как диск, и обработать все IOCTL от MountManager'а + IOCTL_SCSI.
IK>Это не нужно. Пусть этим занимается disk.sys. Ваша забота — PDO предоставлять и обрабатывать некоторые IOCTLы и IRP_MJ_SCSI.

А можно поподробней. Кто создаст PDO для этого Virtual Disk?
Какой stack будет в этом случае?

U>>>2. Используя IoRegisterDeviceInterface + GUID_DEVINTERFACE_DISK зарегистрироваться в системе как диск, и обработать все IOCTL от MountManager'а + IOCTL_SCSI.
IK>>Это не нужно. Пусть этим занимается disk.sys. Ваша забота — PDO предоставлять и обрабатывать некоторые IOCTLы и IRP_MJ_SCSI.

А>А можно поподробней. Кто создаст PDO для этого Virtual Disk?
вы и создаете. См. toaster (bus driver).
А>Какой stack будет в этом случае?
такой же, как и в случае обычного диска.

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

U>>>>2. Используя IoRegisterDeviceInterface + GUID_DEVINTERFACE_DISK зарегистрироваться в системе как диск, и обработать все IOCTL от MountManager'а + IOCTL_SCSI.
IK>>>Это не нужно. Пусть этим занимается disk.sys. Ваша забота — PDO предоставлять и обрабатывать некоторые IOCTLы и IRP_MJ_SCSI.

А>>А можно поподробней. Кто создаст PDO для этого Virtual Disk?
IK>вы и создаете. См. toaster (bus driver).
А>>Какой stack будет в этом случае?
IK>такой же, как и в случае обычного диска.
Дело в том что disk.sys в основном не обрабатывает IOCTL а пересылает IOCTL к low stack driver. Например IOCTL_DISK_GET_DRIVE_GEOMETRY. Параметры этого IOCTL заполняются не disk.sys.
Поэтому необходим лежащий ниже disk.sys или сразу ниже Partition Manager. Но в этом случае будет другой тип drive.И он будет обрабатывать все IOCTL от Partition Manager.

Здравствуйте, eagersh, Вы писали:
...
E>Поэтому необходим лежащий ниже disk.sys или сразу ниже Partition Manager. Но в этом случае будет другой тип drive.И он будет обрабатывать все IOCTL от Partition Manager.
Зачем?

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

E>>Поэтому необходим лежащий ниже disk.sys или сразу ниже Partition Manager. Но в этом случае будет другой тип drive.И он будет обрабатывать все IOCTL от Partition Manager.
IK>Зачем?
Что зачем? Кто будет обрабатывать все запросы от Partition Manager? disk.sys этого не делает. Он пересылает IOCTL запросы на драйвер лежащий ниже в стеке.
Reference: WDK\src\storage\class\disk\

Все же вариант с йоктлами возможно не самый лучший тк при подкличении диска даже при наличии поддержки всех йоктлов его придеться ИМПОРТИРОВАТЬ.
причем если вы будете подключять дин диски созданные на разных системах одновременно то они объединяться в одну группу и потом при новом подключении таких дисков по отдельности вы будете видеть пропущенные диски. да и продумайте как будете обрабатывать волумы raid5,raid0,raid1,spanned. ведь для этого нужно подключать все диски одновоременно иначе у них перестанут совпадать времена создания и их нужно будет импортировать тоже. вариант с парсом структуры диска выглядит лучше с точки зрения юзабилити, тк позволяет избежать всех этих проблем.

E>>>Поэтому необходим лежащий ниже disk.sys или сразу ниже Partition Manager. Но в этом случае будет другой тип drive.И он будет обрабатывать все IOCTL от Partition Manager.
IK>>Зачем?
E>Что зачем? Кто будет обрабатывать все запросы от Partition Manager? disk.sys этого не делает. Он пересылает IOCTL запросы на драйвер лежащий ниже в стеке.
E>Reference: WDK\src\storage\class\disk\

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

A>Все же вариант с йоктлами возможно не самый лучший тк при подкличении диска даже при наличии поддержки всех йоктлов его придеться ИМПОРТИРОВАТЬ.
A>причем если вы будете подключять дин диски созданные на разных системах одновременно то они объединяться в одну группу и потом при новом подключении таких дисков по отдельности вы будете видеть пропущенные диски. да и продумайте как будете обрабатывать волумы raid5,raid0,raid1,spanned. ведь для этого нужно подключать все диски одновоременно иначе у них перестанут совпадать времена создания и их нужно будет импортировать тоже. вариант с парсом структуры диска выглядит лучше с точки зрения юзабилити, тк позволяет избежать всех этих проблем.

Если операции импортирования избежать никак нельзя (я так понимаю, проблема будет при любом способе эмуляции диска, даже с минипортом?), то это может действительно стать проблемой для кастомера. Кстати, импортирование требует write-доступа к диску? У нас сейчас используется строго read-only, и не факт, что доступ к образу на запись будет вообще.

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

E>>>Поэтому необходим лежащий ниже disk.sys или сразу ниже Partition Manager. Но в этом случае будет другой тип drive.И он будет обрабатывать все IOCTL от Partition Manager.
IK>>Зачем?
E>Что зачем?
другой тип drive
E>Кто будет обрабатывать все запросы от Partition Manager?
драйвер шины
E>disk.sys этого не делает. Он пересылает IOCTL запросы на драйвер лежащий ниже в стеке.
E>Reference: WDK\src\storage\class\disk\

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

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

E>>Что зачем? Кто будет обрабатывать все запросы от Partition Manager? disk.sys этого не делает.
SS>А что это за запросы? partmgr это просто вехний фильтр диска, который мониторит изменения в таблице разделов, с тем чтобы вовремя нотифицировать pnp о создании/удалении раздела.

А я и не спорю.Изначально спор был о том что disk.sys будет
делать всю работу.Это не так.Надо bus driver который будет создавать Virtual Disk. Virtual Disk также будет создавать PDO для каждой partion.

E>>Он пересылает IOCTL запросы на драйвер лежащий ниже в стеке.
SS>драйвер, лежащий ниже в стеке — это scsi(stor)-port. Касательно ioctl, котрые он должен обрабатывать см. ntddscsi.h

Ulin который создал пост писал что он не создает Virtual SCSI mini-port. Он выбрал схему legacy Virtual Disk. При этой схеме
the driver будет получать большое количество IOCTL запросов при инициализации,например DISK_GEOMETRY. Некоторые запросы можно пропустить но в большинстве случае надо их правильно обработать.



E>>Reference: WDK\src\storage\class\disk\
SS>кстати, в WDK тяжело читать disk.sys, т.к. его функциональность теперь несколько размазана. Чисто в образовательных целях я бы рекомендовал изучать по исходникам из c:\WINDDK\3790.1830\src\storage\class\disk\

К сожелению это почти единственный source где можно посмотреть
какие запросы получает any disk driver. Хотя disk.sys не показывает как эти IOCTL обрабатывать, но это лучше чем ничего.
3790.1830 build is very old. The latest is WDK 7100.0.0.

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

U>Если операции импортирования избежать никак нельзя (я так понимаю, проблема будет при любом способе эмуляции диска, даже с минипортом?), то это может действительно стать проблемой для кастомера. Кстати, импортирование требует write-доступа к диску? У нас сейчас используется строго read-only, и не факт, что доступ к образу на запись будет вообще.
А как вы создаете ваш диск?

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

U>>Если операции импортирования избежать никак нельзя (я так понимаю, проблема будет при любом способе эмуляции диска, даже с минипортом?), то это может действительно стать проблемой для кастомера. Кстати, импортирование требует write-доступа к диску? У нас сейчас используется строго read-only, и не факт, что доступ к образу на запись будет вообще.
E>А как вы создаете ваш диск?

Я писал в первом посте: "В текущем виде драйвер практически всю работу делает сам ручками: при монтировании диска сам сканит MBR (IoReadPartitionTable), детектит партишены и создает девайсы для каждого из вольюмов.". Собственно, как раз работу по детектингу партишенов (включая те, что в LDM) и хотелось бы переложить на кого-то другого, судя по всему на class driver.

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

E>>А как вы создаете ваш диск?

U>Я писал в первом посте: "В текущем виде драйвер практически всю работу делает сам ручками: при монтировании диска сам сканит MBR (IoReadPartitionTable), детектит партишены и создает девайсы для каждого из вольюмов.". Собственно, как раз работу по детектингу партишенов (включая те, что в LDM) и хотелось бы переложить на кого-то другого, судя по всему на class driver.
А какой нижний интерфейс? Если network то можно использовать еще и iSCSI. Но я сним мало знаком и что нибудь дельное посоветовать не могу.

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

U>>Я писал в первом посте: "В текущем виде драйвер практически всю работу делает сам ручками: при монтировании диска сам сканит MBR (IoReadPartitionTable), детектит партишены и создает девайсы для каждого из вольюмов.". Собственно, как раз работу по детектингу партишенов (включая те, что в LDM) и хотелось бы переложить на кого-то другого, судя по всему на class driver.
E>А какой нижний интерфейс? Если network то можно использовать еще и iSCSI. Но я сним мало знаком и что нибудь дельное посоветовать не могу.

Непосредственно образ диска полностью абстрактный — я просто форварджу все IO в user-mode, где их обрабатывает один из динамически подключаемых плагинов.

Насколько я понял, покопавшись еще немного в этой теме, получив от bus'а PDO для очередного замонтированного диска, мне достаточно создать такой FDO, к которому PnP подключит сверху storage class driver (disk.sys). Где-то еще выше станет PartitionManager. Соответственно, disk.sys начнет выполнять всю грязную работу по распознаванию партишенов, посылая моему девайсу некоторые IOCTL (вроде GET_DISK_GEOMETRY, но не GET_DRIVE_LAYOUT), и пачку запросов на чтение (я так понимаю, уже в виде SRB, а не как IRP). Соответственно, моей основной заботой с этого момента станет обработка read/write. Поправьте меня, плиз, если я где-то в этой общей схеме не прав.

В общем, теперь возникает вопрос, как собственно заставить PnP manager'а прицепить ко мне наверх disk.sys. Просмотр msdn пока ничего не дает на эту тему. Этот момент (именно касательно disk.sys, или в виде какого-то шаблона, из которого можно вывести мой случай) вообще где-то документирован?

Все, что я пока нашел, это один пост на osronline, из которого я понял, что мой PDO должен иметь некий специфический HardwareId (GenDisk вроде бы). А подключаемый в стек новый девайс должен иметь тип MASS_STORAGE

Здравствуйте, Ulin, Вы писали:
да в общем случае требуется доступ на запись

U>Если операции импортирования избежать никак нельзя (я так понимаю, проблема будет при любом способе эмуляции диска, даже с минипортом?), то это может действительно стать проблемой для кастомера. Кстати, импортирование требует write-доступа к диску? У нас сейчас используется строго read-only, и не факт, что доступ к образу на запись будет вообще.

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

я конечно не очень уверен в словах но по моему pdo для дин дисков создает dmio.sys

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

IK>А что именно вас интересует "именно касательно disk.sys". В обсуждаемом отношении у него нет никакой специфики.

Я имел в виду те специфичные ID, благодаря которым подцепится именно disk. Собственно, я так понял вы на них ссылку ниже и приводите.
Эти же ID упоминались и в том посте, про который я говорил. Только там Maxim Shatskih немного не такую картинку дает, как в MSDN написано.

В общем, попробовал я и как Максим писал, и как в MSDN:

DeviceId: L"SCSI\\DiskVENDORX_XXX_____________0004"

HardwareIds: L"SCSI\\DiskVENDORX_XXX_____________\0" \
L"SCSI\\DiskVENDORX_\0" \
L"SCSI\\DiskVENDORX_XXX_____________0\0" \
L"VENDORX_XXX_____________0\0\0" \

InstanceId: L"00&00&01" // encode Path/Target/Lun in hex, separated with &.

CompatibleIDs: L"GenDisk"

Результат, в принципе, одинаковый — в списке устройств в категории DiskDrives появляется новый диск. Правда, с восклицательным знаком.
По логам видно следующее:

PDO IRP_MN_QUERY_RESOURCE_REQUIREMENTS
PDO IRP_MN_QUERY_BUS_INFORMATION
PDO IRP_MN_QUERY_RESOURCES
PDO IRP_MN_REMOVE_DEVICE

DeviceTree от OSRONLINE показывает мой новый PDO с выставленными мной IDs — с виду все гуд.

Я так понимаю, теперь проблема в том, что не обрабатываются уже какие-то disk-specific запросы? Или я где-то что-то недоговорил PnP manager'у (вроде resources)?

U>DeviceTree от OSRONLINE показывает мой новый PDO с выставленными мной IDs — с виду все гуд.

небольшое уточнение — PDO в этом дереве никто не подхватил — ниже уже никто не attached

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

U>Я так понимаю, теперь проблема в том, что не обрабатываются уже какие-то disk-specific запросы? Или я где-то что-то недоговорил PnP manager'у (вроде resources)?

Все, кажется, разобрался сам — действительно, начали сыпаться IRP_MJ_SCSI. После обработки самых первых (типа SRB_FUNCTION_CLAIM_DEVICE и SRB_FUNCTION_EXECUTE_SCSI) к моему PDO успешно приаттачилось все, что нужно.

Еще раз всем спасибо!

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

U>Только там Maxim Shatskih немного не такую картинку дает, как в MSDN написано.
Я так понял, что это то же самое

U>В общем, попробовал я и как Максим писал, и как в MSDN:

U>DeviceId: L"SCSI\\DiskVENDORX_XXX_____________0004"

U>HardwareIds: L"SCSI\\DiskVENDORX_XXX_____________\0" \
U> L"SCSI\\DiskVENDORX_\0" \
U> L"SCSI\\DiskVENDORX_XXX_____________0\0" \
U> L"VENDORX_XXX_____________0\0\0" \

U>InstanceId: L"00&00&01" // encode Path/Target/Lun in hex, separated with &.

U>CompatibleIDs: L"GenDisk"
InstanceId необязательно

U>Результат, в принципе, одинаковый — в списке устройств в категории DiskDrives появляется новый диск.
Ну, все правильно. Первый шаг сделан.
U>Правда, с восклицательным знаком.
А это означает, что после первого шага нужны другие: Disk.sys загружается, вызывается его AddDevice с вашим PDO; пытается с ним что-то делать и не получается — возвращает код ошибкию Отсюда и IRP_MN_REMOVE_DEVICE.
U>По логам видно следующее:

U>PDO IRP_MN_QUERY_RESOURCE_REQUIREMENTS
U>PDO IRP_MN_QUERY_BUS_INFORMATION
U>PDO IRP_MN_QUERY_RESOURCES
Это нормально — при добавлении девайса
U>PDO IRP_MN_REMOVE_DEVICE
А это — результат неудачи в disk.sys!AddDevice

U>DeviceTree от OSRONLINE показывает мой новый PDO с выставленными мной IDs — с виду все гуд.
хорошо
U>Я так понимаю, теперь проблема в том, что не обрабатываются уже какие-то disk-specific запросы?
Именно так
U>Или я где-то что-то недоговорил PnP manager'у (вроде resources)?
Чтобы разобраться, можно скомпилировать отладочные версии disk.sys и classpnp.sys и посмотреть в отладчике, что происходит.

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

A>я конечно не очень уверен в словах но по моему pdo для дин дисков создает dmio.sys
DMIO I/O operations
Disk class driver на рисунке — это disk.sys.

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

IK>Чтобы разобраться, можно скомпилировать отладочные версии disk.sys и classpnp.sys и посмотреть в отладчике, что происходит.

Можно также attach upper class filter который будет переxватывать все PnP, Power и IOCTL Irps и посмотреть какие запросы приходят на реальный hard drive. Это вы увидите все что приходит перед disk.sys. И посмотреть все что идет после
disk.sys attach lower class filter. Example is in toaster sample directory of WDK.

У меня вопрос. Какой type of driver вы используете для Object bus driver? MASS_STORAGE, FILE_CONTROLLER или FILE_DEVICE_UNKNOWN?

E>У меня вопрос. Какой type of driver вы используете для Object bus driver? MASS_STORAGE, FILE_CONTROLLER или FILE_DEVICE_UNKNOWN?
FILE_DEVICE_MASS_STORAGE