Идеология Port/Miniport

Разработчики Windows NT очень любят Port/Miniport модель драйверов.

_Port_ драйвер (почти) всегда загружен. Он занимается общением с ОС, реализует общую функциональность для драйверов определенного класса устройств (например работа с прерываниями, получение аппаратных ресурсов - портов ввода вывода, диапазонов памяти, и т.п., занимается регистрацией устройства в системе, и т.д.). С другой стороны, _Port_ драйвер экспортирует удобное (не всегда :) API для _MiniPort_ драйвера (см. ниже).

_MiniPort_ драйвер может загружаться автоматически или при помощи PnP-manager'а. _MiniPort_ содержит код поиска и инициализации устройств, а также обрабатывает набор стандартных для данного класса устройств запросов, передаваемых _Port_ драйвером.

Например если scsiminiport (atapi, uniata) проинформировал scsiport о найденых устройствах и их параметрах, то scsiport создаст необходимые device object'ы, настроит обработчик прерываний и сообщит операционной системе о найденом оборудовании.

UniATA

Первая версия использовала scsiport.sys для регистрации в системе найденых устройств и требуемых ими ресурсов. Всю грязную работу (создание device object'ов, инициализация обработчика прерываний, управление очередью запросов и т.п. делал scsiport.sys.

Позже, когда возникла необходимлсть борьбы с ограничениями scsiport'а (невозможность поиска неизвестных, но IDE-совместимых PCI устройств, проблемы с PIO/DMA на одном канале, пересортировка очереди, параллельное функционирование IDE каналов на контроллерах с 1 прерыванием) пришлось использовать Kernel API вместо scsiport API.

На текущий момент основная проблема - PnP млдель драйверов в w2k/XP. Изначально UniATA разрабатывался для того, чтобы работать на _любом_ IDE-совместимом контроллере на _любом_ компьютере без переустановки драйверов. При установке драйвера устройства PnP manager запоминает для кагого оборудования этот драйвер предназначается. При последующих загрузках операционки PnP manager строит список оборудования и смотрит в registry, какой драйвер следует загрузить. Если попытаться подключить HDD к другой плате (с другим контроллером), PnP manager не сможет найти подходящего драйвера - вот и приехали.

Другое дело - устройства, о существовании которых нужно просто знать (non pnp-enumerated). Драйвер такого устройства будет загружен в любом случае. Если такой драйвер просканирует PCI шину на предмет IDE контроллеров и сообщит о найденых ScsiPort'у, PnP manager решит, что в системе есть не pnp-совместимые устройства и заблокирует Sleep/Hibernate вместе с IDE hot-swap.

Все эти грабли произростают из архитектуры scsiport'а.

В резельтате обсуждения с Виталием мы пришли к следующему выводу: Для w2k/XP UniATA требуется собственный аналог scsiport, который будет всегда показывать операционке либо 1 (виртуальный) контроллер с кучей шин, либо набор виртуальных (и железо-независимых) контроллеров. Поиск совместимых устройств бедут производиться в тайне от ОС (и главное - PnP manager'а).

Таким образом мы получим логический(ие) контроллер(ы) с неизменной нумерацией как это было в NT4. (Мне кажется, что это была гораздо более надежная и правильная архитектура)

Еще потребуется драйвер-заглушка, который будет устанавливаться для каждого найденого устройства. Сам этот драйвер не будет ничего делать, PnP manager будет счастлив, а всей работой с устройством по-прежнему будет заниматься основной драйвер вируального контроллера.