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

N>Объясни, пожалуйста, в чем заключается отличие в реализации драйверов
N>типа class, miniport, minidriver, function, filter driver.

class driver — обычно это высокоуровневый драйвер предоставляющий независимую отжелеза поддержку для целого класса устройств. Соотв class driver общается в свою очередь с port driver (or another name is miniclass — but I prefer to call it "port driver") который уже реализует реальную обработку запросов посылаемых ему class driver — т.е. тут уже для конкретного железа код идет. Но и этого часто оказывается мало — и появляется miniport driver имеет некоторый интерфейс специфичный для конкретного девайса, но который например может быть OS-specific — т.е. фактически сюда сводится весь интерфейс между драйвером и системой.

к слову обычно это (class driver, port and miniports) даже не драйвера, а dll режима ядра предоставляющая сервисы

Итак все выглядит примерно так:

1. приложение обращается к драйверу

2. тот обрабатывая запрос IRP — пользуется сервисом class driver в виде dll (пример classpnp.sys)

3. верхнеуровневый class driver получает IRP — скажем команда IRP_MJ_READ 4Mb, но устройство может только по 128 Кб transfers делать — class driver может это дело сам аккуратно раздробить на кучу мелких пакетов, выровнять на требуемую границу, озаботитья синхронизацией всей этой ботвы на уровне контроллера\шины и т.п. — короче тут удобно соблюсти все нужные условия облегчающие реализацию port driver и фактически реализовать независимый от конкретного устройства сервис. Что и делается.

4. Затем уже свои подзапросики class driver отправляет следующему — драйверу порта (port driver). Тот соотв может быть уже довольно простым т.к. многие предположения о падающих ему запросах уже гарантированы class driver. Не надо думать как там буфер где выровнен, частично проблемы синхронизации уже все решены на уровне выше и т.п. Короче здесь мы можем сосредоточиться на общении с железом определнного типа конкретного производителя. Т.е. в терминах интерфейсам конкретного устройства ниже говорим девайсу — читай 128К и отдаем назад — там class driver все собирает обратно и телемаркет. Пример port driver раз уж взялись за storage stack — atapi.sys.

5. Но это еще не все — реально нам в итоге нужно пообщаться с HBA (Hardware Bus Driver) или каким-то физическим устройством и уже весьма конкретным. Port driver обычно все зависящие от конкретного девайса вещи прекладывает на минипорт. Их предосталяют уже производители железа — в случае если их устраивает например реализация port driver from MS. Если нет — еще придется попотеть и выкатить свой port driver.

6. Но и это еще не все Если же железо вроде IDE контроллера на шине PCI, то прежде чем atapi.sys поговорит с контроллером и тот соотв с драйвером шины pci.sys, оказывается удобным вынести весь зависимый от типа контроллера (VIA, Intel, etc) интерфейс в отдельную пару драйверов вида порт\минипорт, но называются они уже IDE controller minidrivers Соотв. MS реализует драйвер порта IDE контроллера pciideex.sys а vendors вроде Intel выдают реализацию pciide.sys (native controller minidriver)

7. наконец приехали! pci.sys — HBA

Итого, что все это нам дает?

Получаем:

class — это фактически абстрактный класс (интерфейс) к устройству некоего типа (класса), абсолютно непривязанный к железу. Отсюда и название — class, ООП как никак в действии, хоть и на С все происходит.

port driver — реализация по умолчанию, обычно ее предоставляет MS для системных вещей вроде video, NDIS, storage, keyboard, mouse and so on.

miniport drivers — это уже тюнинг под конкретного производителя — часто это просто крошечные драйверочки знающие только как помочь реализовать запрос от port driver для конкретной железяки (или оптимизировать его).

еще раз подчеркну что это запросто могут быть не отдельные драйвера (в том смысле, что не получится их отдельно как самостоятельный драйвер запустить), а просто набор dll которыми пользуется Ваш (или системный) драйвер для реализации чего-то. Но с точки зрения архитектуры — это несколько уровней драйверов конечно.

Что осталось?

буду краток

functional driver — главный драйвер для устройства (видим по рассказу выше что одно устройство может подерживаться кучей драйверов совместно). Port/miniport pair может рассматриваться в кач-ве functional driver вполне. Короче это реальный интерфейс к устройству.

filter driver — на любой драйвер в WDM модели можно "сесть" и фильтровать как все входящие (Upper filter) пакеты IRP, так и исходящие (Lower filter) от него — те что фильтруемый драйвер отдает по стеку вниз дальше.

Соотв различают Lower/Upper Class filters, Lower/Upper Port filters, etc. Фильтры прекрасны тем что они могут менять поведение как угодно — запрос ориганильно направляемый устройству может быть перехвачен в фильтре, "забыт-проглочен", изменен в серию запросов (class driver) т.е. устройство которое фильтруем вместо 1 увидит несколько запросов или просто заблокировать выполнение запроса или выполнить его иным образом, известным фильтру — и до реального устройства запрос и не дойдет, но вызывающий будет думать что все сделано как надо.

Все приличные antivirus, realtime backup, virtual disks/CD/DVD и прочие классы софта так или иначе пользуются фильтрами для своих нужд, это очень удобный и очень мощный механизм.

N>Пока что у меня довольно расплывчатое представление об этом разделении,
N>кроме того, что я понял, что это чисто логичесие понятия.
N>То есть я ведь могу создать драйвер, соединяющий в себе функциональности, свойственные всем типам?
делайте выводы, в кач-ве домашнего задания

N>Заранее спасибо за терпеливые объяснения!