Driver interface что это

Обновлено: 07.07.2024

Transport Driver Interface - (TDI) разработан SUN, IBM, и Microsoft , TDI программный интерфейс между протоколами и приложениями других уровней в Windows NT network model.

Программная модель TDI

  • Программная модель TDI очень похожа на модель Winsocket. TDI-клиенты реализуют следующие шаги для установления соединения с удаленным сервером:
    1. TDI-клиент формирует пакет TDIIRP типа address open для размещения адреса. TDI-транспорт возвращает файловый объект, известный как объект-адрес, представляющий адрес. Этот шаг эквивалентен использованию функции bind в Winsocket.
    2. TDI-клиент размещает и формирует пакет TDI IRP типа connection open, и TDI-транспорт возвращает файловый объект, известный как объект-соединение, представляющий соединение. Этот шаг эквивалентен использованию функции socket в Winsocket.
    3. TDI-клиент ассоциирует объект-соединение с объектом-адресом с помощью пакета TDI IRP типа associate address.
    4. TDI-клиент, принимающий удаленное соединение, выпускает TDI IRP пакет типа listen, определяющий число соединений, поддерживаемых для объекта-соединения, и затем выпускает пакет TDI IRP типа accept, который завершается, когда удаленная система установит соединение. Эта операция эквивалентна использованию функций listen и accept в Winsocket.
    5. TDI-клиент, который хочет установить соединение с удаленным сервером, выпускает TDI IRP пакет типа connect, определяя объект-соединение, который TDI-транспорт завершает, когда установится соединение. Выпуск TDI IRP пакета типа connect эквивалентно использованию функции connect в Winsocket.

Главные черты TDI

  • Асинхронные операции: Большинство операций в TDI (режим ядра) это асинхронные операции; это значит, что они используют обратный вызов процедур, который обеспечивают TDI клиенты, для определенния любых событий в сети когда-либо происходивших.
  • Гибкая схема адресации: Одна из черт и достоинств использования TDI это то, что TDI предлагает гибкую схему адресации. TDI имеет специальный и расширяемый механизм, который может быть использован в целях поддержки, использования и идентификации различных форматов адресации.
  • Уведомление о событии: Это специальная черта TDI с помощью которой определяется какая схема используется и транспорты могут предупреждать клиентов о любом интересующем событии в сети.
  • 32-битная адресация: Другая черта интерфейса транспортных драйверов это то, что и транспорты и клиенты оба 32 разрядные.
  • Внутренняя буферизация: Эта черта позволяет TDI транспортировать в буфер полученное от клиентов и посылать во внутренний буфер. Эта внутренняя буферизация позволяет TDI клиентам запрашивать и устанавливать размер внутреннего буфера, получая уведомления о доступном пространстве буфера и просматривать данные из буфера даже перед тем как получить их.

• Уведомление о событии (Plug & Play): Интерфейс транспортного драйвера определяет конкретную схему с помощью которой транспорты (in case of Windows 2000 & later versions) могут уведомлять TDI клиента о различных событиях PnP, таких как удаление или добавление соединений и другое.


Как уважаемый хабрапользователь наверняка знает, «драйвер устройства» — это компьютерная программа управляющая строго определенным типом устройства, подключенным к или входящим в состав любого настольного или переносного компьютера.

Основная задача любого драйвера – это предоставление софтового интерфейса для управления устройством, с помощью которого операционная система и другие компьютерные программы получают доступ к функциям данного устройства, «не зная» как конкретно оно используется и работает.

Обычно драйвер общается с устройством через шину или коммуникационную подсистему, к которой подключено непосредственное устройство. Когда программа вызывает процедуру (очередность операций) драйвера – он направляет команды на само устройство. Как только устройство выполнило процедуру («рутину»), данные посылаются обратно в драйвер и уже оттуда в ОС.

Любой драйвер является зависимым от самого устройства и специфичен для каждой операционной системы. Обычно драйверы предоставляют схему прерывания для обработки асинхронных процедур в интерфейсе, зависимом от времени ее исполнения.

Любая операционная система обладает «картой устройств» (которую мы видим в диспетчере устройств), для каждого из которых необходим специфический драйвер. Исключения составляют лишь центральный процессор и оперативная память, которой управляет непосредственно ОС. Для всего остального нужен драйвер, который переводит команды операционной системы в последовательность прерываний – пресловутый «двоичный код».

Как работает драйвер и для чего он нужен?

Основное назначение драйвера – это упрощение процесса программирования работы с устройством.

Он служит «переводчиком» между хардовым (железным) интерфейсом и приложениями или операционными системами, которые их используют. Разработчики могут писать, с помощью драйверов, высокоуровневые приложения и программы не вдаваясь в подробности низкоуровневого функционала каждого из необходимых устройств в отдельности.

Как уже упоминалось, драйвер специфичен для каждого устройства. Он «понимает» все операции, которые устройство может выполнять, а также протокол, с помощью которого происходит взаимодействие между софтовой и железной частью. И, естественно, управляется операционной системой, в которой выполняет конкретной приложение либо отдельная функция самой ОС («печать с помощью принтера»).

Если вы хотите отформатировать жесткий диск, то, упрощенно, этот процесс выглядит следующим образом и имеет определенную последовательность: (1) сначала ОС отправляет команду в драйвер устройства используя команду, которую понимает и драйвер, и операционная система. (2) После этого драйвер конкретного устройства переводит команду в формат, который понимает уже только устройство. (3) Жесткий диск форматирует себя, возвращает результат драйверу, который уже впоследствии переводит эту команду на «язык» операционной системы и выдает результат её пользователю (4).

Как создается драйвер устройства


Для каждого устройства существует свой строгий порядок выполнения команд, называемой «инструкцией». Не зная инструкцию к устройству, невозможно написать для него драйвер, так как низкоуровневые машинные команды являются двоичным кодом (прерываниями) которые на выходе отправляют в драйвер результат, полученный в ходе выполнения этой самой инструкции.

При создании драйвера для Линукса, вам необходимо знать не только тип шины и ее адрес, но и схематику самого устройства, а также весь набор электрических прерываний, в ходе исполнения которых устройство отдает результат драйверу.

Написание любого драйвера начинается с его «скелета» — то есть самых основных команд вроде «включения/выключения» и заканчивая специфическими для данного устройства параметрами.

И чем драйвер не является

Часто драйвер устройства сравнивается с другими программами, выполняющими роль «посредника» между софтом и/или железом. Для того, чтобы расставить точки над «i», уточняем:

  • Драйвер не является интерпретатором, так как не исполняется напрямую в софтовом слое приложения или операционной системы.
  • Драйвер не является компилятором, так как не переводит команды из одного софтового слоя в другой, такой же.

Ну и на правах рекламы – вы всегда знаете, где скачать новейшие драйвера для любых устройств под ОС Windows.

Сетевые драйверы можно разделить на 2 категории: TDI-драйверы (Transport Driver Interface) и NDIS-драйверы (Network Driver Interface Specification). TDI-драйверы — это высокоуровневые драйверы, например, SMB-клиент, SMB-сервер, обертки SMB (NFFS, MSFS) и т.п. Мы с Вами рассмотрим NDIS-драйвера. NDIS — это специальный драйвер (ему соответствует файл ndis.sys), который содержит функции, используемые низкоуровневыми сетевыми драйверами. NDIS как бы обволакивает низкоуровневые сетевые драйверы и является посредником в их общении между собой и с железом. По сути NDIS можно считать третьим ядром Windows. Чтобы более четко уяснить себе что из себя представляет NDIS можно посмтореть на следующую картинку:

  • Минипорт-драйверы (драйверы адаптера)
  • Промежуточные драйверы (например, psched.sys)
  • Драйверы протокола (например, tcpip.sys)

Минипорт-драйверы

  • производит инициализацию своего устройства (адаптера)
  • создание /включение/выключение/удаление сетевых подключений
  • выдача клиенту или изменение параметров адаптера
  • отправка пакетов
  • получение пакетов
  • оповещение ОС о состоянии адаптера
  • перезагрузка и остановка адаптера

Минипорт-драйверы бывают «Connectionless» (например, драйвер Ethernet-адаптера) и «Сonnection-oriented» (например, драйвер модема). У Сonnection-oriented драйверов система коллбэков чуть сложнее, в нее входят обработчики событий, связанных с подключением к каналу связи, отключением от канала, выбором канала (для беспроводных адаптеров) и т.п. Для некоторых операций Сonnection-oriented драйверы вызывают специальные функции NDIS, отличающиеся префиксом «Со» в имени (например, вместо NdisMIndicateReceivePacket Сonnection-oriented драйвер должен вызывать NdisMColndicateReceivePacket).

Каждый коллбэк выполняет свою задачу: выдача информации, отправка данных, прием данных и т.п. Подробнее можно посмотреть в хелпе к WDK (DDK). Там можно получить полную информацию о коллбэках.

Драйверы протоколов могут передоверять минипорт-драйверу (при условии, что минипорт-драйвер это умеет — либо сам, либо адаптер умеет это делать на аппаратном уровне) некоторые свои функции (например, разграничить контрольную сумму или цифровую подпись IP-пакета или принять решение, как фрагментировать большой ТСP-пакет). Это значительно повышает производитель сети.

  1. LBFO (Load Balancing and Fail Over) — позволяет понимающим его адаптерам распределять между собой исходящий трафик и исправлять ошибки друг друга. Впрочем, что имеет смысл только на backbone routers (центральных маршрутизаторах больших сетей), на которые редко ставят Windows
  2. FFP (Fast Forwarding Path) — позволяет понимающим его адаптерам маршрутизировать/фильтровать пакеты чисто аппаратно, вообще без участия ОС и не нагружая основные процессоры компьютера

Промежуточные драйверы

Промежуточный драйвер сверху виден как минипорт-драйвер (смотрим на картинку), т.е. как бы виртуальный адаптер, а снизу — как драйвер протокола (снова смотрим на картинку), как бы виртуальный протокол. Как частный случай, возможна ситуация, когда промежуточный драйвер виден только сверху.

  • организуют «справедливый» доступ разных клиентских программ к адаптерам дабы программы не мешали друг другу
  • фильтруют и перехватывают трафик
  • маршрутизируют пакеты из одной сети в другую, если эти сети различаются (например, Ethernet и WI-FI)
Драйверы протоколов

Драйверы протокола — это самый верхний уровень спецификации NDIS. Эти драйверы занимаются тем, что выделяют ресурсы для соответствующих пакетов, копируют данные приложений в пакеты и передают их драйверам нижнего уровня. Также драйверы протоколов обеспечивают интерфейс для получения пакетов от нижележащих драйверов.

К драйверам протоколов относятся и драйверы транспорта, реализующие стек сетевых протоколов, такой как например TCP/IP (tspip.sys).

Если пост будет интересен читателям, то в следующих постах можно конкретно на примере написать свой сниферо-подобный промежуточный драйвер или также описать как написать каждый из типов драйверов (минипорта, промежуточный или протокола).

Я хочу поделиться с вами простым способом установки ADB драйвера под Windows. Эта статья понадобится тем, у кого этот драйвер или не устанавливается вовсе, или устанавливается, но adb все равно в упор не видит устройство(как было у меня), или вы вообще этот драйвер не нашли. Так что всех, у кого есть/были похожие проблемы, или кому просто интересно, прошу под кат.

Начну с предыстории. Решил я купить себе недорогой планшетик на Android для чтения книг(DJVU/PDF), и выбор пал на устройство российского конечно же китайского производства TeXet TM-7025. Жаба давила покупать что-то дорогое, а для простого чтения книг каких-то сверх-характеристик не требуется. Позже я обнаружил что на нем неплохо идут большинство игрушек, удобно полазить в инете пока ты сидишь in da kabin и т. д. А поскольку передо мной маячило изучение Android, я решил, что будет весьма удобно пользоваться для этого железным девайсом вместо мучений с эмуляторами.

И вот тут меня ждал неприятный сюрприз — то ли родной драйвер оказался кривым, то ли винда, то ли провод… вообщем драйвер то встал, диспетчер устройств Windows рапортовал о полной работоспособности девайса, но на запрос adb devices в консоли я получал пустой список и, естественно, тестировать приложение на планшете не удавалось.

Я написал запрос в службу поддержки TeXeT, мне даже ответили ссылкой на сам драйвер, который, как я уже убедился, не работал. Я начал искать ответ в интернете и нашел кучу разных сборок этого драйвера и мануалов, но все равно ни один из них не завелся как надо, и даже родной драйвер из SDK вообще никак не становился, что повергло меня в уныние… но не отчаяние.

Вот тут я решил попробовать свои силы в написании драйверов старом добром методе научного тыка и открыл inf-файл драйвера. Надежду мне давало понимание, что софтверная часть adb интерфейса со стороны планшета должна быть идентичной для всех устройств, а USB и так работал. И вот, после нескольких неудачных проб ручной правки inf-файла я нашел рецепт лечения приправы inf-файла так, чтобы оно поставилось и, главное, работало.

Шаг 3. Правим inf-файл. В папочке открываем файл android_winusb.inf и ищем там строки такого вот вида:


Делаем копию этих строк, заменяем Google Nexus One на %имя_вашего_девайса% для идентификации в будущем и… открываем диспетчер устройств Windows. Ищем там наше устройство(Android, Android Composite ADB Interface или что-то в этом стиле). Открываем свойства устройства, вкладка «Сведения», в списке выбираем пункт «ИД оборудования» и видим такую вот картину.

Копируем строчку, которая больше всего похожа на ту, что показана на рисунке(Она, по идее просто немного короче), и вставляем ее в наш inf-файл.


В %SingleAdbInterface% мы конец строки удаляем, как видно, в %CompositeAdbInterface% вставляем целиком. Повторять два раза все, наверное, не надо, но у меня уже все стоит и мне лень экспериментировать :)
Сохраняемся(будьте внимательны — в некоторых случаях для этого нужно запускать блокнот с правами администратора, т. к. в пользовательском режиме вам не дадут перезаписать inf-файл).
Шаг 4. Установка драйвера. Теперь, когда все подготовлено, возвращаемся в диспетчер устройств и удаляем все ранее установленные adb драйверы(если были). Обновляем список устройств и видим наш девайс без драйверов. Открываем его свойства и выбираем «обновить драйверы», выбираем установку из папки, указываем папку с поправленым inf-ом и запускаем установку — наш драйвер моментально находится, но при установке он может ругаться о несовместимости с вопросом «продолжать ли, насяльнека?». Продолжаем. Все, драйвер установлен.
Шаг 5. Финал. Для точности делаем вынь-всунь USB-порта, ждем пока все обнаруживается, открываем консоль(Win+R, вводим cmd) и пишем adb devices. Если все прошло хорошо — видим заветный пункт списка, обозначающий, что adb теперь видит наш девайс.

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

Если команда adb у вас вообще не работает. Компьютер -> Свойства -> Переменные среды. Ищем переменную Path и в конце дописываем(ни в коем случае не перезаписываем) в конце точку с запятой, а после адрес папки, где живет adb(обычно %android-sdk%\platform-tools\). После перезагрузки должно заработать.
Иногда adb не запускается автоматически при старте системы. Запустите вручную.

Что это было?
На самом деле все просто. В силу неких причин(винда мастдай/у прогеров кривые руки/гугловский инф-файл писался только для родных гугловских девайсов/в вашем компьютере все испортили бозоны Хиггса) винда не хочет кушать гугловский драйвер для негугловских девайсов, не записанніх в inf-файл. Видимо, там все как раз завязано на этих ИД-оборудования. Но ведь софтверная часть на подавляющем большинстве андроид-устройств в части дебаггер-коннектора к ПК идентична, потому драйвер должен нормально общаться с любым Андроид-устройством. Наша задача — обмануть Windows и заставить ее принять девайс за «драйверо-подходящий», что мы и сделали путем дописывания его ИД в inf-файл драйвера.

Надеюсь, кому-то данный мануал поможет завести свой китайский или другой девайс, для которого при сборке системы забыли сделать нормальный драйвер adb, или тем, кого задалбывает качать официальный драйвер от производителя устройства(это бывает настолько гемморно, что быстрей сделать все вышеописанное — у меня так было с драйвером для телефона LG E510).

Читайте также: