Основы разработки прикладных виртуальных драйверов


Содержание

Основы разработки драйверов устройств в операционных системах Windows

В предыдущих главах этой книги для управления различными устройствами мы использова ли свободно распространяемое программное обеспечение, куда входил драйвер PortTalk.sys и программа allowio.exe. В этой главе мы рассмотрим вопросы создания собственных драйве ров устройств в операционных системах Windows, а также создадим драйвер для управления аналого цифровым преобразователем, подключенным к параллельному порту ПК.

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

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

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

Для разработки драйверов мы будем применять стандартное свободно распространяе мое программное средство, выпущенное фирмой Microsoft – Windows DDK (Driver Develop ment Kit). Этот программный пакет можно закачать с сайта Microsoft. В его состав включена обширная документация вместе с примерами разработок драйверов.

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

Начнем с того, что определим, что собой представляет драйвер устройства, и как он вза имодействует с операционной системой. В упрощенном виде такую схему взаимодействия можно представить следующей схемой (рис. 7.1):

Ошибка программы при попытке записи

в параллельный порт

Команды ассемблера in и out являются «привилегированными» инструкциями процессора Intel и могут выполняться только программами, работающими на уровне ядра системы, поэто му пользовательская программа и завершается аварийным образом.

К ресурсам системы напрямую могут обращаться некоторые системные программы и большинство драйверов устройств. Для того чтобы пользовательская программа могла рабо тать с привилегированными инструкциями процессора и обращаться напрямую к аппарат ным ресурсам системы, нужно дать ей доступ на уровне ядра, сняв бит защиты в контексте процесса. Эти функции для примеров в предыдущих главах выполняли драйвер PortTalk.sys и программа allowio.exe.

Есть и другой путь для работы с устройствами пользователя – написать самому драйвер устройства и обращаться к нему из программы пользователя. Именно этот путь и будет здесь описан. Для того чтобы реализовать такую возможность нужно сделать два шага:

1) написать драйвер устройства;

2) написать программу, которая бы обращалась к драйверу устройства для выполнения операций ввода вывода.

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

Источник: Магда Ю. С. Компьютер в домашней лаборатории. – М.: ДМК Пресс, 2008. – 200 с.: ил.

Многоуровневые драйверы

Первоначально термин «драйвер» применялся в достаточно узком смысле: под драйвером понимался программный модуль, который:

· входит в состав ядра операционной системы, работая в привилегированном режиме;

· непосредственно управляет внешним устройством, взаимодействуя с его контроллером с помощью команд ввода-вывода компьютера;

· обрабатывает прерывания от контроллера устройства;

· предоставляет прикладному программисту удобный логический интерфейс работы с устройством, экранируя от него низкоуровневые детали управления устройством и организации его данных;

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

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

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

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

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

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

Высокоуровневые драйверы оформляются по тем же правилам и придерживаются тех же внутренних интерфейсов, что и аппаратные драйверы. Единственным отличием является то, что высокоуровневые драйверы, как правило, не вызываются по прерываниям, так как взаимодействуют с управляемым устройством через посредничество аппаратных драйверов. Менеджер ввода-вывода управляет драйверами однотипно, независимо от того, к какому уровню он относится. При наличии большого количества драйверов разного уровня усложняются связи между ними, что, в свою очередь, усложняет их взаимодействие, и именно эта ситуация привела к стандартизации внутреннего интерфейса в подсистеме ввода-вывода и выделения специальной оболочки в виде менеджера ввода-вывода, выполняющего служебные функции по организации работы драйверов.

Рассмотрим, как общие принципы построения многоуровневых драйверов могут быть реализованы при управлении определенными типами внешних устройств.

В подсистеме управления дисками аппаратные драйверы поддерживают для верхних уровней представление диска как последовательного набора блоков одинакового размера, преобразуя вместе с контроллером номер блока в более сложный адрес, состоящий из номеров цилиндра, головки и сектора. Однако такие понятия, как «файл» и «файловая система», аппаратные драйверы дисков не поддерживают – эти удобные для пользователя и программиста логические абстракции создаются на более высоком уровне программным обеспечением файловых систем, которое в современных ОС также оформляется как драйвер, только высокоуровневый. Наличие универсальной среды, создаваемой менеджером ввода-вывода, позволяет достаточно просто решить проблему поддержки в ОС нескольких файловых систем одновременно. Для этого в ОС устанавливается несколько высокоуровневых драйверов (на рисунке это драйверы файловых систем ufs, FAT, и NTFS), работающих с общими аппаратными драйверами, но по-своему организующими хранение данных в блоках диска и по-своему представляющими файловую систему пользователю и прикладным процессам. Для унификации представления различных файловых систем в подсистеме ввода-вывода может использоваться общий драйвер верхнего уровня, играющий роль диспетчера нескольких драйверов файловых систем. На рисунке в качестве примера показан диспетчер VFS (Virtual File System), применяемый в операционных системах UNIX, реали- зованных на основе кода System V Rе1еаве 4.

Необязательно все модули подсистемы ввода-вывода оформляются в виде драйверов. Например, в подсистеме управлениями дисками обычно имеется такой модуль, как дисковый кэш, который служит для кэширования блоков дисковых файлов в оперативной памяти. Достаточно специфические функции кэша делают нецелесообразным оформление его в виде драйвера, взаимодействующего с другими модулями ОС только с помощью услуг менеджера ввода-вывода. Другим примером модуля, который чаще всего не оформляется, является диспетчер окон графического интерфейса. Иногда этот модуль вообще выносится из ядра ОС и реализуется в виде пользовательского процесса. Таким образом был реализован диспетчер окон (а также высокоуровневые графические драйверы) в Windows NT 3.5 и 3.51, но этот микроядерный подход заметно замедлял графические операции, поэтому в Windows NT 4.0 диспетчер окон и высокоуровневые графические драйверы, а также графическая библиотека GDI были перенесены в пространство ядра.

Аппаратные драйверы после запуска операции ввода-вывода должны своевременно реагировать на завершение контроллером заданного действия, и для решения этой задачи они взаимодействуют с системой прерываний. Драйверы более выcоких уровней вызываются уже не по прерываниям, а по инициативе аппаратных драйверов или драйверов вышележащего уровня. Не все процедуры аппаратного драйвера нужно вызывать по прерываниям, поэтому драйвер обычно имеет определенную структуру, в которой выделяется секция обработки прерываний (Interrupt Service Routine — ISR), которая и вызывается при поступлении запроса от соответствующего устройства диспетчером прерываний. Диспетчер прерываний можно считать частью подсистемы ввода-вывода, как это показано на рис. 1, а можно считать и независимым модулем ядра ОС, так как он служит не только для вызова секций обработки прерываний драйверов, но и для диспетчеризации прерываний других типов.

В унификацию драйверов большой вклад внесла операционная система UNIX. В ней все драйверы были разделены на два больших класса: блок-ориентированные (block-oriented) драйверы и байт-ориентированные (character-oriented) драйверы. Это деление является более общим, чем деление на вертикальные подсистемы. Например, драйверы графических устройств и драйверы сетевых устройств относятся к классу байт-ориентированных.

Блок-ориентированные драйверы управляют устройствами прямого доступа, которые хранят информацию в блоках фиксированного размера, каждый из которых имеет собственный адрес. Самое распространенное внешнее устройство прямого доступа — диск. Адресуемость блоков приводит к тому, что для устройств прямого доступа появляется возможность кэширования данных в оперативной памяти, и это обстоятельство значительно влияет на общую организацию ввода- вывода для блок-ориентированных драйверов.

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

Блок- или байт-ориентированность является характеристикой как самого устройства, так и драйвера. Очевидно, что если устройство не поддерживает обмен адресуемыми блоками данных, а позволяет записывать или считывать последовательность байт, то и устройство, и его драйвер можно назвать байт-ориентированными. Для байт-ориентированного устройства невозможно разработать блок- ориентированный драйвер. Устройство прямого доступа с блочной адресацией является блок-ориентированным, и для управления им естественно использовать блок-ориентированный драйвер. Однако блок-ориентированным устройством можно управлять и с помощью байт-ориентированного драйвера. Так, диск можно рассматривать не только как набор блоков, но и как набор байт, первый из которых начинает первый блок диска, а последний завершает последний блок. Физический обмен с контроллером устройства по-прежнему осуществляется блоками, но байт-ориентированный драйвер устройства будет преобразовывать блоки в последовательность байт. Для устройств прямого доступа часто разрабатывают пару драйверов, чтобы к устройству можно было обращаться и по байт- ориентированному, и по блок-ориентированному интерфейсам в зависимости от потребностей.

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

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

Не нашли то, что искали? Воспользуйтесь поиском:

Форумы Modlabs.net: Программирование драйверов устройств для чайников — Форумы Modlabs.net

Программирование драйверов устройств для чайников

#1 dE fENDER

  • Группа: Пользователи
  • Сообщений: 265
  • Регистрация: 18 December 08

#2 dE fENDER

  • Группа: Пользователи
  • Сообщений: 265
  • Регистрация: 18 December 08

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

Также эти уроки могут помочь аудитории владельцев видеокарт с графическими чипами, произведенными компанией 3dfx, разобраться в доступных исходных кодах драйверов этих видеокарт. Упомянутые исходники могут быть с наименьшим количеством переделок откомпилированы под Windows XP/Windows 2003 Server, которые и будут являться основной целевой системой. В более современной Windows Vista/7 несколько изменилась модель драйверов, наиболее сильно это затронуло графическую подсистему. Это означает, что для их корректной работы придется переписать весьма значительную часть кода. Кроме того, под х64 версиями Vista/7 и более старших операционных систем просто так нельзя загрузить драйвер, не имеющей цифровой подписи. Подпись стоит порядка 500 долларов в год (150, если найти купон на скидку), их не любят давать частным лицам и даже небольшим организациям. Кроме того, если в подписанном драйвере обнаружится уязвимость и ей воспользуются хакеры – то подпись данного [почти всегда юридического] лица аннулируется и у него возникают проблемы с получением новой. Еще есть такая процедура, как WHQL-сертификация, но ее я вообще не собираюсь пока здесь обсуждать.

Весьма приветствуется, если другие люди будут давать здесь свои собственные уроки, не выходящие за пределы темы. Также здесь можно задавать любые вопросы, предлагать свои идеи для следующих уроков и отписываться об своих удачных/неудачных результатах.

Для начала работы требуется иметь некоторое знакомство с любым языком программирования. Думаю, для этого вполне достаточно школьного / вузовского курса для непрограммистов. Если же в современных программах образования знакомство с программированием не было предусмотрено/за давностью лет курс забыт или просто что-то непонятно – отписывайтесь в теме, я напишу другие уроки, подробней раскрывающие непонятную тему.

#3 White

  • Белый человер
  • Группа: Главный Администратор
  • Сообщений: 11517
  • Регистрация: 16 July 05

#4 dE fENDER

  • Группа: Пользователи
  • Сообщений: 265
  • Регистрация: 18 December 08

Урок 0. Установка и настройка программного обеспечения

Список используемого программного обеспечения:

  • Windows XР или Windows 2003 Server х86 – операционная система, под которую будем писать драйверы;
  • Visual Studio 2010 – среда разработки приложений на языках С/С++ и других. Будет использоваться для написания различных простых прикладных программ, в т.ч. и управляющей программы драйвера. Можно попробовать воспользоваться Visual Studio 11 beta, которая доступна для скачивания по ссылке — http://www.microsoft. studio/11/en-us;
  • Windows Driver Kit – набор инструментов, необходимых для разработки драйвера. Включает в себя компилятор, заголовочные файлы и много другого. Требуется версия 7.1.0, ее можно взять по ссылке
    http://www.microsoft. ang=en& >
  • VMWare – при отсутствии физической машины операционную систему можно запустить в виртуальной. Это также безопаснее при разработке — при ошибке в драйвере система уйдет в синий экран;
  • Daemon Tools – средство для открытия образов CD и DVD дисков в формате iso. WDK распространяется в виде такого образа. В случае использования VMWare использовать не обязательно, т.к. VMWare умеет монтировать такие образы самостоятельно. Бесплатную lite-версию можно скачать здесь: http://www.disc-tool. download/daemon
  • DebugView – утилита Марка Руссиновича, которая позволяет увидеть текстовые сообщения, выдаваемые драйверами, собранными в отладочном режиме. Скачивать здесь — http://technet.micro. ernals/bb896647
  • Far Manager – файловый менеджер, с которым легче работать с консольными утилитами. Взять можно здесь — http://www.farmanage. wnload.php?l=ru.

Все используемое мною программное обеспечение – на английском языке. В большинстве случаев можно использовать и русские версии, но может возникнуть путаница в командах или другие проблемы с совместимостью. Для начала работы потребуется компьютер с установленной обычной 32-разрядной Windows XP/2003. Продвинутые пользователи могут пользоваться необычной – отладочной, она же — checked build. Эта версия показывает больше информации при отладке устройств. Обычная же версия Windows носит название free build. Компьютер для экспериментов может быть как реальным, так и виртуальным. Разрабатываемые программы я буду проверять на одной реальной машине и одной виртуальной. На обоих установлен Windows Server 2003 R2 Enterprise Edition c SP2. Виртуальная машина запущена под VMWare Workstation 8.0.2.

Установка Visual Studio
Я буду использовать Visual Studio 2010 Ultimate. В принципе, ставить ее не обязательно, так как все необходимые инструменты, включая компилятор и заголовки есть и в WDK. Но для написания прикладных программ, в особенности для новичка, она намного удобней вызова компилятора из консоли. Если ее все же планируется установить, то лучше делать это перед установкой WDK.

Берем диск со студией в iso-формате, монтируем его в Daemon Tools, либо подключаем как компакт-дисковод в VMWare. Запускаем с диска setup.exe, выбираем «Install Microsoft Visual Studio 2010». На следующем шаге под Windows 2003 может появится сообщение, что требуется Windows Imaging Component. Щелкаем по этой строке, запускается браузер – скачиваем подходящий по языку операционной системы (у меня английский, значит wic_x86_enu.exe), устанавливаем. Заново запускаем setup.exe с диска. Нажимаем Next, соглашаемся с лицензионным соглашением, затем идет выбор типа установки. Выбираем Custom, изменяем путь установки – для избежания ошибок Visual Studio и все любые другие инструменты следует ставить по максимально короткому пути без русских букв и пробелов. Мой вариант – C:\Programs\VS10. Следующая страница – выбор пакетов. Устанавливаем в соответствии с рисунком:

Рис 0.1 – Выбор пакетов в установщике Visual Studio


Кроме показанных, можно также выбрать «Visual C#». C# бывает полезен для расширения возможностей самой Visual Studio и написания небольших утилит. Нажимаем Install. Кроме самой студии ставится куча бесполезной, ненужной и вредной дряни. Если на компьютере была старая версия Windows Installer’а – потребуется перезагрузка. После установки – Finish, Exit.

Установка WDK
Монтируем скачанный iso-образ аналогично тому, как это было сделано с Visual Studio. Запускаем KitSetup.exe, на этапе выбора пакетов устанавливаем галочки в соответствии с рисунком:

Рис 0.2 – Выбор пакетов в установщике WDK

Нажимаем Ок, укорачиваем путь установки до C:\WinDDK, может появится окно установки .net 2.0. Устанавливаем .net. Появляется окно с лицензией WDK, соглашаемся. Ждем завершения установки. Нажимаем Finish. Установочный диск WDK не удаляем, а сохраняем до лучших времен, предыдущую версию 7.0 невозможно было корректно удалить без образа именно того диска, с которого ее устанавливали.

Илон Маск рекомендует:  Что такое код globaldeleteatom

Устанавливать Visual Studio и WDK не обязательно на той же машине, на которой планируется проверять работу программ. Для проверки я поставил их на реальной машине с Windows 7 х64 и откомпилировал драйвер, который заработал под Windows 2003 Server х86.
Создаем на диске каталог для проектов, учитывая вышеописанные рекомендации (без пробелов и русских букв), например C:\Projects. Запускаем Visual Studio, открываем настройки (меню Tools/Option), выбираем в дереве «Projects and Solutions/General», в параметре Projects location выбираем/указываем созданный каталог.

Также настоятельно рекомендую установить Far Manager 2 и работать через него. Его преимущество над Windows/Total Commander’ами и Explorer’ами в том, что через него нормально видно содержимое консоли (команда ctrl + O), куда выдается полезная информация при компиляции и запуске консольных программ. Путь установки желательно записать в переменную PATH.

В дальнейшем рассмотрим и драйверы для Windows 9x. Для этого потребуется другое программное обеспечение, но программирование драйверов для Windows 9x проще.

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

Драйвер

Драйвер – компьютерное программное обеспечение, используемое для управления каждым подключенным к компьютеру устройством ввода-вывода, учитывая его особенности. Оно создается производителем устройства и поставляется вместе с этим устройством. Поскольку для каждой операционной системы нужны собственные драйверы, производитель устройства обычно поставляет драйверы для нескольких наиболее популярных операционных систем.

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

Содержание

Драйвер и операционная система

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

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

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

В некоторых системах операционная система представляет собой единую программу в двоичных кодах, в которой содержатся все необходимые ей скомпилированные драйверы. Такая схема долгие годы была нормой для систем семейства UNIX, поскольку они работали в компьютерных центрах, где устройства ввода-вывода менялись очень редко. При добавлении нового устройства системный администратор просто перекомпилировал ядро с новым драйвером для создания нового двоичного кода.

С наступлением эры персональных компьютеров с несметным количеством устройств ввода-вывода эта модель уже не работает. Лишь немногие пользователи способны перекомпилировать или перекомпоновать ядро, даже если у них будут исходные коды или объектные модули, что случается довольно редко. Вместо этого операционные системы, начиная с MS-DOS, перешли к модели, в которой драйверы стали динамически загружаться в систему в процессе работы. Управление загрузкой драйверов ведется в разных системах по-разному.

Алгоритм работы

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

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

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

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

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

Функции программного обеспечения, не зависящего от конкретных устройств

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

Предоставление унифицированного интерфейса для драйверов устройств

Одной из острых проблем при создании операционных систем является придание всем устройствам и драйверам ввода-вывода более или менее однообразного вида.

Один из аспектов этой проблемы — интерфейс между драйверами устройств и остальной операционной системой. На рис. 2 (а) показана ситуация, в которой у каждого драйвера устройства имеется собственный интерфейс с операционной системой. Это означает, что функции драйвера, доступные для вызова системой, различаются от драйвера к драйверу. Это может означать, что и функции ядра, в которых нуждается драйвер, различаются от драйвера к драйверу. Все вместе взятое это означает, что обеспечение интерфейса с каждым новым драйвером требует множества новых усилий по созданию программного кода.

В противоположность этому на рис. 2 (б) показана другая конструкция, в которой у всех драйверов имеется одинаковый интерфейс. Теперь стало намного проще подключить новый драйвер, обеспечив его соответствие интерфейсу драйверов. Также это означает, что создатели драйверов знают, чего от них ожидают. Фактически не все устройства абсолютно одинаковы, но обычно приходится иметь дело лишь с небольшим количеством типов устройств, и даже они в целом практически одинаковы.

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

Буферизация

Буферизация по многим причинам также является актуальным вопросом как для блочных, так и для символьных устройств. Чтобы понять, в чем состоит одна из таких причин, рассмотрим процесс, которому необходимо прочитать данные, получаемые от ADSL-модема, который многие используют дома для связи с Интернетом. По одной из возможных стратегий работы с поступающими символами нужно заставить пользовательский процесс осуществить системный вызов READ и заблокироваться в ожидании одного символа. При этом прерывание возникает по случаю поступления каждого символа. Процедура обработки прерывания передает символ пользовательскому процессу и снимает с него блокировку. Поместив куда-нибудь символ, процесс переходит к чтению следующего символа и снова блокируется.

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

В улучшенном варианте пользовательский процесс предоставляет буфер объемом N символов и выполняет чтение такого же количества символов. Процедура обработки прерывания помещает поступающие символы в этот буфер до тех пор, пока он не заполнится. Затем она возобновляет работу пользовательского процесса. Эта схема работает намного эффективнее предыдущей, но у нее есть один недостаток. Что получится, если буфер выйдет за границу страницы при поступлении очередного символа? Буфер будет зафиксирован в памяти, но если множество процессов начнет фиксировать страницы в памяти, то запас доступных страниц сократится и производительность резко снизится.

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

Буферизация является широко используемой технологией, но у нее имеются и недостатки. Если данные будут подвергаться буферизации слишком часто, упадет производительность. Рассмотрим, к примеру, сеть, показанную на рис. 4. Здесь пользовательский процесс осуществляет системный вызов для записи данных по сети. Ядро копирует пакет данных в буфер ядра, позволяя пользовательскому процессу немедленно возобновить работу (шаг 1). Теперь пользовательская программа может использовать буфер повторно.

Когда вызывается драйвер, он копирует пакет в контроллер для его последующего вывода (шаг 2). Причина, по которой он не осуществляет вывод в сеть непосредственно из памяти ядра, состоит в том, что как только будет запущена передача пакета, она должна продолжаться на постоянной скорости. Драйвер не может гарантировать, что он будет получать доступ к памяти на постоянной скорости, поскольку множество циклов обращения к шине могут отвлекать на себя каналы DMA и другие устройства ввода-вывода. Неудача при своевременном получении слова приведет к порче пакета. Эту проблему можно устранить за счет буферизации пакета внутри контроллера.

После того как пакет будет скопирован во внутренний буфер контроллера, он копируется в сеть (шаг 3). Биты поступают получателю вскоре после их отправки, поэтому сразу же после отправки последнего бита этот бит поступает получателю, у которого пакет попадает в буфер контроллера. Затем пакет копируется в буфер ядра получателя (шаг 4). И наконец он копируется в буфер процесса получателя (шаг 5). Обычно после этого получатель посылает подтверждение. Когда отправитель получает подтверждение, он имеет возможность послать следующий пакет. Но при этом следует понимать, что операции копирования существенно снижают скорость передачи данных, поскольку шаги должны осуществляться последовательно.

Сообщение об ошибках

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

К одному из классов ошибок ввода-вывода относятся ошибки программирования. Они возникают в том случае, если процесс запрашивает что-нибудь невозможное, к примеру запись в устройство ввода информации или чтение из устройства вывода информации. Другие ошибки возникают при предоставлении неверного адреса буфера или указании неверного устройства. На такие ошибки следует весьма простая реакция: вызывающей программе отправляется код возникшей ошибки.

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

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

Распределение и высвобождение выделенных устройств

Некоторые устройства, в любой момент времени могут использоваться только одним процессом. Операционная система должна проверять запросы на использование и принимать их или отвергать в зависимости от доступности запрашиваемого устройства. Простой способ обработки этих запросов заключается в требовании к процессам непосредственно открывать специальные файлы для этих устройств с помощью системных вызовов OPEN. Если устройство недоступно, то системный вызов OPEN потерпит неудачу. Освобождение выделенного устройства происходит после его закрытия с помощью системного вызова CLOSE. Альтернативный подход заключается в использовании специальных механизмов для запроса и освобождения выделенных устройств. Попытка получить в свое распоряжение недоступное устройство приводит не к отказу, а к блокировке процесса, предпринявшего эту попытку. Заблокированные процессы помещаются в очередь. Рано или поздно запрашиваемое устройство станет доступным, и первому процессу из этой очереди будет позволено получить устройство и продолжить свою работу.

Предоставление размера блока, не зависящего от конкретных устройств

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

Горячее подключение устройств

В системе, допускающей горячее подключение, устройство может быть добавлено или удалено во время работы компьютера. В результате, пока драйвер занят чтением с какого-нибудь устройства, система может ему сообщить, что пользователь внезапно удалил это устройство из системы. Драйверу придется не только прервать текущую передачу данных, не повредив при этом каких-либо структур данных ядра, но и умудриться элегантно удалить из системы все отложенные запросы для только что удаленного устройства и сообщить плохие новости пославшим их программам. Более того, неожиданное добавление новых устройств может заставить ядро перераспределить ресурсы, забирая у драйвера старые и предоставляя вместо них новые.

Виртуальные драйверы

Драйверы виртуальных устройств представляют собой особый вариант драйверов. Они используются для эмуляции аппаратного устройства, особенно в средах виртуализации, например, когда программа DOS запускается на компьютере Microsoft Windows. Вместо того, чтобы разрешать гостевой операционной системе взаимодействовать с настоящим оборудованием, драйверы виртуальных устройств принимают противоположную роль и эмулируют часть оборудования, так что гостевая операционная система и ее драйверы, запущенные внутри виртуальной машины, имеют только иллюзию доступа к нему. Попытки гостевой операционной системы получить доступ к оборудованию маршрутизируются к драйверу виртуального устройства в операционной системе хоста. Драйвер виртуального устройства также может посылать в виртуальную машину смоделированные события уровня процессора, такие как прерывания.

Курсовая работа: Разработка драйвера виртуального жесткого диска

Кафедра: Программное обеспечение ЭВМ и информационные технологии

на тему: Разработка драйвера виртуального жесткого диска

1. АНАЛИТИЧЕСКИЙ РАЗДЕЛ.. 4

1.1 Постановка задачи. 4

1.2 Архитектура Windows 2000. 4

1.3 Многослойная архитектура драйверов. 5

1.4 Архитектура драйверов устройств хранения. 8

1.5 Выбор файловой системы.. 9

2. КОНСТРУКТОРСКИЙ РАЗДЕЛ.. 11

2.1 Структура классового драйвера. 11

2.2 Организация внутреннего хранения данных диска. 12

2.3 Доступ к передаваемым данным. 13

2.4 Обработка запросов Plug and Play. 14

2.5 Обработка расширенных запросов. 15

2.7 Расчет геометрии диска. 16

2.6 Структура драйвера. 17

3. ТЕХНОЛОГИЧЕСКИЙ РАЗДЕЛ.. 18

3.1 Выбор и обоснование языка и среды программирования. 18

3.2 Структуры данных классового драйвера. 18

3.3 Блокировка выгрузки устройства. 19

3.4 Процедуры драйвера виртуального диска. 19

3.4.1 Инициализация драйвера. 19

3.4.2Обработка запросов записи/чтения. 22

3.4.3 Обработка расширенных запросов. 24

3.4.4 Обработка запросов Plug and Play. 26

3.4.5 Выгрузка драйвера. 28

3.5 Программа настройки параметров виртуального диска. 29


3.6 Установка драйвера. 29

4. ЭКСПЕРИМЕНТАЛЬНО-ИССЛЕДОВАТЕЛЬСКИЙ РАЗДЕЛ.. 31

4.1 Описание экспериментов. 31

4.2 Результаты экспериментов. 31

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ.. 33

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

Самым распространенным устройством для хранения данных в настоящее время является жесткий диск, который умеет хранить большие объемы данных. Время доступа к произвольному месту на диске зависит от скорости перемещения считывающей головки. Но быстродействие механики диска имеет предел, и время ответа для жесткого диска на несколько порядков выше, чем для оперативной памяти. Поэтому производительность при множественных операциях чтения и записи к различным данным катастрофически падает.

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

Однако буферизация только на основе оперативной памяти в подсистеме ввода-вывода оказывается недостаточной — разница между скоростью обмена с оперативной памятью, куда процессы помещают данные для обработки, и скоростью работы внешнего устройства часто становится слишком значительной, чтобы в качестве временного буфера можно было бы использовать оперативную память — ее объема может просто не хватить. Для таких случаев необходимо предусмотреть особые меры, и часто в качестве буфера используется дисковый файл, называемый также спул-файлом (от spool — шпулька, тоже буфер, только для ниток). Типичный пример применения спулинга дает организация вывода данных на принтер. Для печатаемых документов объем в несколько десятков мегабайт — не редкость, поэтому для их временного хранения (а печать каждого документа занимает от нескольких минут до десятков минут) объема оперативной памяти явно недостаточно.

Другой подход для хранения данных в памяти – создание Ram дисков. В систему добавляется виртуальный диск, а образ диска расположен в оперативной памяти. Такой подход позволяет повысить быстродействие, когда приложение использует обращения случайного чтения, случайной записи. Так например, значительную часть всех обращений к данным в современных СУБД составляют случайные запросы на чтение данных. Другое преимущество виртуальных дисков – их можно использовать для бездисковых рабочих станций для промежуточных файлов.

1. АНАЛИТИЧЕСКИЙ РАЗДЕЛ

1.1 Постановка задачи

К разрабатываемому драйверу виртуального диска предъявляются следующие требования:

1. Разрабатываемый драйвер должен добавлять в операционную систему новый виртуальный диск

2. Для увеличения скорости передачи, драйвер должен работать в блочном режиме передачи данных

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

4. Драйвер должен определять объем свободной физической памяти и ограничивать размер создаваемого виртуального диска.

5. Драйвер может динамически выгружаться из системы и загружаться в нее без необходимости перезагружать компьютер

6. Поскольку операции чтения записи, создания, переименования и удаления файлов выполняет драйвер файловой системы, то нужно обеспечивать считывание и запись необходимых файловой системе данных.

7. Работа драйвера не должна влиять на работу других драйверов.

1.2 Архитектура Windows 2000

Наиболее распространены реализации Windows 2000 для платформы Intel x86 в одно- или многопроцессорных конфигурациях, однако существуют также версии для DEC Alpha и MIPS. Данная операционная система использует защищённый режим центрального процессора, реализует механизмы виртуальной памяти и многопоточности.

Исполняемый код в Windows 2000 может исполняться в двух уровнях привилегий: пользовательском режиме и режиме ядра . Уровень привилегий накладывает определённые ограничения: в пользовательском режиме не могут выполняться привилегированные инструкции процессора и не разрешено обращение к защищённым страницам в памяти. Эти ограничения накладываются для обеспечения безопасности работы системы. Пользовательское приложение не должно иметь возможность — в результате ошибки или преднамеренно — вносить изменения в критические таблицы операционной системы или в память других приложений. В частности, такие ограничения запрещают пользовательскому приложению напрямую управлять внешними устройствами, потому что каждое из них является разделяемым ресурсом .

В Windows 2000 обеспечение обмена данными и управление доступом к внешнему устройству как к разделяемому ресурсу возлагается на его драйвер . Ввод и вывод в драйверах осуществляется пакетами — IRP (Input/Output Request Packet). Запросы на ввод/вывод, посылаемые приложениями или другими драйверами, обрабатываются драйвером, после чего запрашивающей программе в том же пакете посылается статус завершения операции. Общий принцип взаимодействия проиллюстрирован на рис. 1.

Рис. 1 . Архитектура ввода/вывода Windows 2000.

1.3 Многослойная архитектура драйверов

Рассмотрим как строится архитектура драйверов. Операционная система Windows® поддерживает многослойную архитектуру драйверов. Каждое устройство обслуживается цепочкой драйверов, называемой стеком драйверов. Каждый драйвер в стеке изолирует аппаратно зависимые возможности от вышестоящего уровня.

На рис. 2 показаны типы драйверов, которые могут обслуживать устройство. В действительности, некоторые из этих типов могут отсутствовать в стеке.

Рис. 2 Многослойная архитектура драйверов

1. Над стеком находятся приложения. Они обрабатывают запросы пользователя или других приложений и вызывают или подсистему Win 32 или клиент драйвер пользовательского режима.

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

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

4. Классовый и мини классовый драйвер устройства предоставляет основной набор сервисов обслуживания. Классовый драйвер предоставляет аппаратно независимую поддержку для специфичного класса устройств. Мини классовый драйвер обрабатывает отдельные операции для устройства из этого класса.

5. Порт-драйвер (для некоторых устройств это драйвер хост-контроллера или хост-адаптера) выполняет требуемые операции ввода/вывода для порта, хаба или другого физического устройства, через которое осуществляется подключение. От типа устройства и шины через которую оно подключено зависит будет ли присутствовать этот драйвер в стеке. Все драйвера устройств хранения имеют порт-драйвер. Например, SCSI порт драйвер выполняет ввод/вывод через шину SCSI.

Мини порт-драйвер обрабатывает специфичные операции порт-драйвера.

6. Драйвер аппаратной шины находится в самом низу стека. Microsoft предоставляет эти драйвера для всех шин, как часть операционной системы.

1.4 Архитектура драйверов устройств хранения

Для того, чтобы определить какой тип драйвера потребуется разработать, рассмотрим более подробно структуру взаимодействие драйверов устройств хранения в цепочке драйверов.

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

Рис. 3 Архитектура драйверов устройств хранения

Запрос ввода/вывода от приложений пользователя обрабатывается подсистемой ввода/вывода. Подсистема формирует пакет запроса на ввод/вывод(IRP), который приходит классовому драйверу устройства ввода вывода через один или несколько промежуточных драйверов фильтров верхнего уровня(таких как например драйвер файловой системы).

Классовый драйвер ввода вывода дополняет полученный пакет IRP дополнительным SCSI блоком запроса (SRB) и посылает запрос порт драйверу через фильтр драйверы нижнего уровня.

Порт-драйвер полученные пакеты SRB преобразует к формату для передачи по аппаратной шине, и посылает их адаптеру главной шины (HBA), через драйвер вводы вывода шины и один или несколько фильтр драйверов.

Благодаря тому, что виртуальный диск не является реальным физическим устройством, нам не требуется производить доступ к аппаратной шине и формировать специальные пакеты SRB. Данные в оперативной памяти уже доступны на уровне классового драйвера; нецелесообразно и не нужно передавать IRP пакеты на нижний уровень.

Таким образом, требуется разработать классовый драйвер, в который будет происходить вся обработка запросов и обращение к данным диска для нашего класса устройств виртуального диска.

1.5 Выбор файловой системы

Для того, чтобы начать работу с диском, диск разбивается на разделы. Раздел — это непрерывная часть физического диска, которую операционная система представляет пользователю как логическое устройство (используются также названия логический диск и логический раздел). Именно с логическими устройствами работает пользователь, обращаясь к ним по символьным именам, используя, например, обозначения А, В, С. В частном случае, когда все дисковое пространство охватывается одним разделом, логическое устройство представляет физическое устройство в целом.

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

На каждом логическом устройстве может создаваться только одна файловая система. Для дисковых накопителей Windows поддерживает файловые системы FAT и NTFS.

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

Отличительные свойства NTFS[2], то что она ориентирована для поддержки больших файлов, восстанавливаемости после сбоев и отказов программ и аппаратуры управления дисками – все это приводит к значительному размеру метаданных. Поэтому минимальный размер тома равен 10 Мб, а на практике использование NTFS оправдано для логических дисков от 400 Мб.

Файловая система FAT относится к ФС с глобальным индексом, и поэтому метаданные состоят из метки тома, глобальной таблицы диска и коневого каталога. Все остальное место свободное и отводится под создаваемые файлы и каталоги. Тот факт , что при каждой операции чтения/ записи идет обращение к таблице FAT не влияет на производительность, т.к. время доступа для оперативной памяти ничтожно мало по сравнению с жестким диском. Также существует несколько версия FAT: 12, 16 и 32. FAT 12 можно использовать на маленьких дисках от 1 Мб. Использование FAT 32 в основном предназначена для томов объемом в несколько Гб, и минимальный размер тома ограничен 512 Мб, этому она не подходит для виртуального диска.

Таким образом для нашего виртуального диска будет использоваться файловые системы FAT 12(когда объем диска не превышает 16 Мб) и FAT 16.

2. КОНСТРУКТОРСКИЙ РАЗДЕЛ

2.1 Структура классового драйвера

Драйвер реализуется как набор процедур, каждая из которых предназначена для реализации отдельного типа обращений к драйверу со стороны диспетчера ввода/вывода. Процедуры, которые необходимо поддерживать классовому драйверу приведены в таблице 1.

Выполняется при загрузке драйвера операционной системой. Здесь драйвер регистрирует свои остальные точки входа и выполняет свою общую инициализацию.

Вызывается при выгрузке драйвера. Здесь необходимо освободить все затребованные ресурсы.

Здесь создаётся объект-устройство, соответствующий полученному уведомлению от менеджера устройств, и выполняется инициализация данных, специфичных для данного устройства.

Выполняет обработку специфичных Plug&Play запросов , таких как инициализация устройства, таких как инициализация устройства, остановка, удаление устройства и обрабатывать остальные запроса

Выполняет обработку запросов по управлению питанием устройства

Обрабатывает запросы от подсистемы инструментария Windows (WMI)

Обслуживают запросы на чтение запись данных для устройства.

2.2 Организация внутреннего хранения данных диска

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

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

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

Следующим шагом выберем, каким образом мы зарезервируем память для диска. Для резервирования памяти в режиме ядра Windows предоставляет специальные системные вызовы. Существуют следующие типы резервируемой памяти:

· Страничная память(Paged memory) – виртуальная память, которая может быть перемещена системой на жесткий диск в любой момент времени. В случае, если приложение обратиться к отсутствующей в физической памяти области своей виртуальной памяти, то возникает исключение по отсутствию страницы в памяти. В результате системный обработчик перехватывает это исключение и загружает в физическую память отсутствующую страницу. Однако при работе в режиме ядра, когда уровень приоритета равен или выше DISPATCH_LEVEL, это исключение создаст ситуацию, когда системный обработчик не может подгрузить страницу т.к. его IRQL меньше текущего.

· Нестраничная память(Nonpaged memory) – эта память никогда не может быть перемещена системой на жесткий диск и всегда остается в физической оперативной памяти. В результате, обращаться к этой памяти можно при любом уровне IRQL. Объем данной памяти ограничен даже при наличии достаточного объема физической памяти в Windows 2000 660 Мбайтами, а в Windows XP 1300 Мбайтами.

Поскольку обращение к образу диска происходит при уровне привилегий PASSIVE_LEVEL или DISPATCH_LEVEL, но в особых ситуациях этот приоритет может быть выше. Поэтому во избежание возникновения ситуации, когда страница отсутствует в памяти, и мы ее не сможем подгрузить – виртуальный диск будет использовать нестраничную память. Дополнительно мы увеличим быстродействие драйвера, т.к. уже не требуется подгружать отсутствующие страницы с жесткого диска.

2.3 Доступ к передаваемым данным

Рассмотрим, каким образом драйвер может получить доступ к передаваемым данным. Пользовательский процесс, вызывая функцию API (например, WriteFile), передаёт ей указатель на буфер, в котором размещается записываемая информация. Однако, передаваемый виртуальный адрес действительно будет указывать на записываемую информацию только в контексте данного процесса. Операции же ввода/вывода в драйвере происходят в контексте произвольного процесса. Из-за смены таблиц страничного преобразования при переключении процессов использовать переданный виртуальный адрес в произвольном контексте совершенно недопустимо.

Для операций ввода/вывода архитектура операционной предусматривает два специальных метода передачи буфера данных, принадлежащего инициатору запроса:

· Буферизированный (buffered I/O). Драйверу в пакете запроса ввода/вывода передаётся указатель на копию исходного буфера в невыгружаемой памяти (поле AssociatedIrp.SystemBuffer). Подсистема ввода/вывода отвечает за точное соответствие содержимого этого буфера передаваемым данным. Этот метод, в основном, используется для устройств, не предающих больших объёмов данных: манипуляторы, низкоскоростные коммуникационные линии и т. п.

· Прямой (direct I/O). В этом случае система блокирует страницы пользовательского буфера, чтобы они не были выгружены на диск во время передачи данных. Расположение пользовательского буфера в физической памяти описывается структурой MDL (Memory Descriptor List), доступной в пакете запроса ввода/вывода через поле MdlAddress. По этой структуре необходимо настроить системную таблицу страниц на тот же буфер в физической памяти. Это осуществляется функцией MmGetSystem, которая возвращает виртуальный адрес буфера в системной области памяти. Данный метод эффективен с большими объёмами данных, например, при работе с дисковыми накопителями.

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

2.4 Обработка запросов Plug and Play

В процессе работы диспетчер ввода вывода может динамически управлять состоянием устройства: запускать, останавливать и выгружать. Реализация этих функций драйвером устройства хранения обеспечивает при обработке специфичных PnP IRP пакетов. В таблице 2 приведены описания IRP пакетов, которые должны поддерживаться.

Инициализация устройства с заданными ресурсами

Проверка осуществимости остановки устройства для перераспределения ресурсов

Остановка устройства с потенциальной возможность. перезапуска или удаления из системы


Уведомляет, что предыдущий запрос на остановку не получит дальнейшего развития

Проверка осуществимости безопасного удаления устройства

Выполнить безопасное удаление устройства

Уведомляет, что предыдущий запрос на удаление не получит дальнейшего развития

Уведомляет, что устройство было удалено без предварительного предупреждения

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

Основным состоянием диска будет WORKING – когда диск находится в рабочем состоянии. Остальные состояния(приведенные в таблице 3) носят информативный характер, чтобы узнать текущий режим работы диска. При операциях доступа к устройству будет осуществляться проверка состояния WORKING, и только при нем доступ к диску разрешен.

Как разработать драйвер виртуального устройства на winapi?

Задание по изучению драйверов на Winapi, хорошо знаю winapi, с драйверами не сталкивался:
— Разработать драйвер (виртуального устройства), который отслеживает запуск некоторого процесса X. При запуске этого процесса драйвер
запускает другой процесс Y. Как только процесс X завершается по какой-то причине, драйвер выгружает процесс Y.
— Разработать драйвер (виртуального устройства), который отслеживает изменения в реестре Windows заданным процессом (или за какое-то время)
и создает на диске журнал.

В чём, кроме блокнота, разрабатывать драйвер?

Что значит создать драйвер виртуального устройства? Это нужно создать виртуальное устройство и на него как-то загрузить драйвер, или достаточно того, что созданный драйвер будет загружен с помощью утилиты InstDrv (с сайта rootkit.com)

PS. За любые ссылки по теме буду признателен, с драйверами раньше не сталкивался, начал с книги «Руткиты: внедрение в ядро Windows» Г. Хоглунд, Дж. Батлер

  • Вопрос задан более двух лет назад
  • 1470 просмотров

Задание по изучению драйверов на Winapi, хорошо знаю winapi

Начну с того, что докопаюсь. Драйвера не имеют доступа к WinAPI. Все Вынапи определено в библиотеках уровня пользователя. Драйвера имеют с уровнем ядра и использует NativeAPI из ntoksrnl.exe

В чём, кроме блокнота, разрабатывать драйвер?

В редакторе кода *trollface*

Visual studio + Windows WDK

Что значит создать драйвер виртуального устройства

Это значит, что будет только драйвер без устройства. Суть в том, что драйвер — это не обязательно связанное с устройствами. Это просто код работающий на 0-м кольце ( в ядре ). Загрузить его можно как и обычно — через службу ( InstDrv делает это все за нас, а после выгрузки удаляет )

в примере HTTP драйвер винды (да, этот протокол реализован через ядро).

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

Сайт с 2006 года мертв :D

Передай это дино-составителям задачи))

книги «Руткиты: внедрение в ядро Windows» Г. Хоглунд, Дж. Батлер

Ну не укладывается, что в универе просят писать руткиты под винду, хоть убей)

Основы разработки драйверов устройств в операционных системах Windows

В предыдущих главах этой книги для управления различными устройствами мы использова ли свободно распространяемое программное обеспечение, куда входил драйвер PortTalk.sys и программа allowio.exe. В этой главе мы рассмотрим вопросы создания собственных драйве ров устройств в операционных системах Windows, а также создадим драйвер для управления аналого цифровым преобразователем, подключенным к параллельному порту ПК.

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

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

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

Для разработки драйверов мы будем применять стандартное свободно распространяе мое программное средство, выпущенное фирмой Microsoft – Windows DDK (Driver Develop ment Kit). Этот программный пакет можно закачать с сайта Microsoft. В его состав включена обширная документация вместе с примерами разработок драйверов.

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

Начнем с того, что определим, что собой представляет драйвер устройства, и как он вза имодействует с операционной системой. В упрощенном виде такую схему взаимодействия можно представить следующей схемой (рис. 7.1):

Ошибка программы при попытке записи

в параллельный порт

Команды ассемблера in и out являются «привилегированными» инструкциями процессора Intel и могут выполняться только программами, работающими на уровне ядра системы, поэто му пользовательская программа и завершается аварийным образом.

К ресурсам системы напрямую могут обращаться некоторые системные программы и большинство драйверов устройств. Для того чтобы пользовательская программа могла рабо тать с привилегированными инструкциями процессора и обращаться напрямую к аппарат ным ресурсам системы, нужно дать ей доступ на уровне ядра, сняв бит защиты в контексте процесса. Эти функции для примеров в предыдущих главах выполняли драйвер PortTalk.sys и программа allowio.exe.

Есть и другой путь для работы с устройствами пользователя – написать самому драйвер устройства и обращаться к нему из программы пользователя. Именно этот путь и будет здесь описан. Для того чтобы реализовать такую возможность нужно сделать два шага:

1) написать драйвер устройства;

2) написать программу, которая бы обращалась к драйверу устройства для выполнения операций ввода вывода.

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

Источник: Магда Ю. С. Компьютер в домашней лаборатории. – М.: ДМК Пресс, 2008. – 200 с.: ил.

Основы разработки прикладных виртуальных драйверов

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

Для ускорения процесса разработки используются специализированные средства, например готовые инструменты для тестирования знаний или программы, заявленные разработчиками как среды, специально направленные на создание лабораторий коллективного пользования. ряд разработок (в том числе и российских) отличается удобством и простой в работе. множество полезных функций позволяет сэкономить время при создании соответствующего раздела лабораторий коллективного пользования. С помощью набора предоставляемых в этих программах инструментов можно проектировать практикумы на основе моделей объектов для организации процесса изучения различных дисциплин [1–15].

Описание унифицированных программных модулей для лаборатории коллективного пользования

В ходе анализа ряда обучающих систем и виртуальных практикумов, а также инструментов для их создания авторами данной статьи было решено спроектировать такое программное обеспечение, которое позволило бы из готовых модулей формировать лаборатории коллективного пользования для изучения различных дисциплин. В состав таких модулей должен входить универсальный измерительный блок [5, 10–14]. С подключенными к блоку объектами можно работать через информационную сеть. Разрабатываемое программное обеспечение должно быть достаточно гибким и поддаваться реконфигурированию, модернизации и перепрофилированию в соответствии с изучаемой предметной областью.

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

Пример структуры для создаваемых программных модулей лаборатории приведен на рисунке.

В первом приближении из структуры можно выделить два крупных программных блока. Первый блок – сервер сбора данных. Этот отдельный большой модуль включает в себе основной механизм выполнения операций измерения физических величин на заданном объекте исследования и операций, связанных с оказанием определенных воздействий на данный объект. В нем используется функционал драйверов NI-DAQ, который позволяет организовать измерения напряжения, деформации, тока, длительности импульсов и цифровых сигналов по настраиваемым виртуальным каналам [10–14]. Результаты измерений легко передать для последующей обработки.

Внутри модуля сбора данных реализуются подмодули, отвечающие за тип ввода/вывода (аналоговый и цифровой). Это сделано с учетом того, что для разных типов операций ввода/вывода принципы работы с устройством сбора данных несколько отличаются. При создании и отладке описываемого модуля это позволяет сосредоточиться на реализации операций конкретного типа ввода/вывода, не отвлекаясь на другие этапы разработки. Такое разделение предполагает использование программы с различными моделями устройств. Например, в качестве объекта исследования используется цифровая микросхема, а аппаратное обеспечение может и не включать плату ввода/вывода с аналоговыми каналами. Достаточно приобрести недорогой цифровой модуль. Для разработчика программного обеспечения это упрощает формирование комплекта комплекса и создает предпосылки для более тонкой настройки под конкретное устройство. Все это позволяет создать такое приложение для сервера сбора данных, которое способно работать на базе различных моделей модулей ввода/вывода и параллельно выполнять измерения с нескольких объектов исследования.

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

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

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

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

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

Общая структурная схема организации программного обеспечения лаборатории коллективного пользования

5. «Модуль справочных данных» позволяет получать справочные данные и теоретические сведения по курсу изучаемой дисциплины из соответствующего раздела базы данных «Справочные материалы». Это может быть полезно для улучшения понимания смысла выполняемой работы и для подготовки к защите.

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

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

Создание интеллектуальной интегрированной интернет лаборатории по инженерным дисциплинам на базе программного продукта для систем сбора данных, их анализа, обработки и визуализации – LabVIEW (Laboratory Virtual Instrument Engineering Workbench) существенно повышает эффективность образовательного процесса по инженерным дисциплинам.

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

Включение в общий контур многоролевых деловых игр и систем поддержки принятия решений при их проведении позволит впервые в мировой практике создать уникальный интеллектуальный интегрированный интернет лабораторный практикум для распределенного дистанционного обучения по инженерным направлениям подготовки.

Курсовая работа: Разработка драйвера виртуального жесткого диска

Название: Разработка драйвера виртуального жесткого диска
Раздел: Рефераты по информатике, программированию
Тип: курсовая работа Добавлен 05:26:00 18 июня 2009 Похожие работы
Просмотров: 1257 Комментариев: 14 Оценило: 3 человек Средний балл: 5 Оценка: неизвестно Скачать

Кафедра: Программное обеспечение ЭВМ и информационные технологии

на тему: Разработка драйвера виртуального жесткого диска

1. АНАЛИТИЧЕСКИЙ РАЗДЕЛ.. 4

1.1 Постановка задачи. 4

1.2 Архитектура Windows 2000. 4

1.3 Многослойная архитектура драйверов. 5

1.4 Архитектура драйверов устройств хранения. 8

1.5 Выбор файловой системы.. 9

2. КОНСТРУКТОРСКИЙ РАЗДЕЛ.. 11

2.1 Структура классового драйвера. 11

2.2 Организация внутреннего хранения данных диска. 12

2.3 Доступ к передаваемым данным. 13

2.4 Обработка запросов Plug and Play. 14


2.5 Обработка расширенных запросов. 15

2.7 Расчет геометрии диска. 16

2.6 Структура драйвера. 17

3. ТЕХНОЛОГИЧЕСКИЙ РАЗДЕЛ.. 18

3.1 Выбор и обоснование языка и среды программирования. 18

3.2 Структуры данных классового драйвера. 18

3.3 Блокировка выгрузки устройства. 19

3.4 Процедуры драйвера виртуального диска. 19

3.4.1 Инициализация драйвера. 19

3.4.2Обработка запросов записи/чтения. 22

3.4.3 Обработка расширенных запросов. 24

3.4.4 Обработка запросов Plug and Play. 26

3.4.5 Выгрузка драйвера. 28

3.5 Программа настройки параметров виртуального диска. 29

3.6 Установка драйвера. 29

4. ЭКСПЕРИМЕНТАЛЬНО-ИССЛЕДОВАТЕЛЬСКИЙ РАЗДЕЛ.. 31

4.1 Описание экспериментов. 31

4.2 Результаты экспериментов. 31

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ.. 33

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

Самым распространенным устройством для хранения данных в настоящее время является жесткий диск, который умеет хранить большие объемы данных. Время доступа к произвольному месту на диске зависит от скорости перемещения считывающей головки. Но быстродействие механики диска имеет предел, и время ответа для жесткого диска на несколько порядков выше, чем для оперативной памяти. Поэтому производительность при множественных операциях чтения и записи к различным данным катастрофически падает.

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

Однако буферизация только на основе оперативной памяти в подсистеме ввода-вывода оказывается недостаточной — разница между скоростью обмена с оперативной памятью, куда процессы помещают данные для обработки, и скоростью работы внешнего устройства часто становится слишком значительной, чтобы в качестве временного буфера можно было бы использовать оперативную память — ее объема может просто не хватить. Для таких случаев необходимо предусмотреть особые меры, и часто в качестве буфера используется дисковый файл, называемый также спул-файлом (от spool — шпулька, тоже буфер, только для ниток). Типичный пример применения спулинга дает организация вывода данных на принтер. Для печатаемых документов объем в несколько десятков мегабайт — не редкость, поэтому для их временного хранения (а печать каждого документа занимает от нескольких минут до десятков минут) объема оперативной памяти явно недостаточно.

Другой подход для хранения данных в памяти – создание Ram дисков. В систему добавляется виртуальный диск, а образ диска расположен в оперативной памяти. Такой подход позволяет повысить быстродействие, когда приложение использует обращения случайного чтения, случайной записи. Так например, значительную часть всех обращений к данным в современных СУБД составляют случайные запросы на чтение данных. Другое преимущество виртуальных дисков – их можно использовать для бездисковых рабочих станций для промежуточных файлов.

1. АНАЛИТИЧЕСКИЙ РАЗДЕЛ

1.1 Постановка задачи

К разрабатываемому драйверу виртуального диска предъявляются следующие требования:

1. Разрабатываемый драйвер должен добавлять в операционную систему новый виртуальный диск

2. Для увеличения скорости передачи, драйвер должен работать в блочном режиме передачи данных

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

4. Драйвер должен определять объем свободной физической памяти и ограничивать размер создаваемого виртуального диска.

5. Драйвер может динамически выгружаться из системы и загружаться в нее без необходимости перезагружать компьютер

6. Поскольку операции чтения записи, создания, переименования и удаления файлов выполняет драйвер файловой системы, то нужно обеспечивать считывание и запись необходимых файловой системе данных.

7. Работа драйвера не должна влиять на работу других драйверов.

1.2 Архитектура Windows 2000

Наиболее распространены реализации Windows 2000 для платформы Intel x86 в одно- или многопроцессорных конфигурациях, однако существуют также версии для DEC Alpha и MIPS. Данная операционная система использует защищённый режим центрального процессора, реализует механизмы виртуальной памяти и многопоточности.

Исполняемый код в Windows 2000 может исполняться в двух уровнях привилегий: пользовательском режиме и режиме ядра . Уровень привилегий накладывает определённые ограничения: в пользовательском режиме не могут выполняться привилегированные инструкции процессора и не разрешено обращение к защищённым страницам в памяти. Эти ограничения накладываются для обеспечения безопасности работы системы. Пользовательское приложение не должно иметь возможность — в результате ошибки или преднамеренно — вносить изменения в критические таблицы операционной системы или в память других приложений. В частности, такие ограничения запрещают пользовательскому приложению напрямую управлять внешними устройствами, потому что каждое из них является разделяемым ресурсом .

В Windows 2000 обеспечение обмена данными и управление доступом к внешнему устройству как к разделяемому ресурсу возлагается на его драйвер . Ввод и вывод в драйверах осуществляется пакетами — IRP (Input/Output Request Packet). Запросы на ввод/вывод, посылаемые приложениями или другими драйверами, обрабатываются драйвером, после чего запрашивающей программе в том же пакете посылается статус завершения операции. Общий принцип взаимодействия проиллюстрирован на рис. 1.

Рис. 1 . Архитектура ввода/вывода Windows 2000.

1.3 Многослойная архитектура драйверов

Рассмотрим как строится архитектура драйверов. Операционная система Windows® поддерживает многослойную архитектуру драйверов. Каждое устройство обслуживается цепочкой драйверов, называемой стеком драйверов. Каждый драйвер в стеке изолирует аппаратно зависимые возможности от вышестоящего уровня.

На рис. 2 показаны типы драйверов, которые могут обслуживать устройство. В действительности, некоторые из этих типов могут отсутствовать в стеке.

Рис. 2 Многослойная архитектура драйверов

1. Над стеком находятся приложения. Они обрабатывают запросы пользователя или других приложений и вызывают или подсистему Win 32 или клиент драйвер пользовательского режима.

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

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

4. Классовый и мини классовый драйвер устройства предоставляет основной набор сервисов обслуживания. Классовый драйвер предоставляет аппаратно независимую поддержку для специфичного класса устройств. Мини классовый драйвер обрабатывает отдельные операции для устройства из этого класса.

5. Порт-драйвер (для некоторых устройств это драйвер хост-контроллера или хост-адаптера) выполняет требуемые операции ввода/вывода для порта, хаба или другого физического устройства, через которое осуществляется подключение. От типа устройства и шины через которую оно подключено зависит будет ли присутствовать этот драйвер в стеке. Все драйвера устройств хранения имеют порт-драйвер. Например, SCSI порт драйвер выполняет ввод/вывод через шину SCSI.

Мини порт-драйвер обрабатывает специфичные операции порт-драйвера.

6. Драйвер аппаратной шины находится в самом низу стека. Microsoft предоставляет эти драйвера для всех шин, как часть операционной системы.

1.4 Архитектура драйверов устройств хранения

Для того, чтобы определить какой тип драйвера потребуется разработать, рассмотрим более подробно структуру взаимодействие драйверов устройств хранения в цепочке драйверов.

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

Рис. 3 Архитектура драйверов устройств хранения

Запрос ввода/вывода от приложений пользователя обрабатывается подсистемой ввода/вывода. Подсистема формирует пакет запроса на ввод/вывод(IRP), который приходит классовому драйверу устройства ввода вывода через один или несколько промежуточных драйверов фильтров верхнего уровня(таких как например драйвер файловой системы).

Классовый драйвер ввода вывода дополняет полученный пакет IRP дополнительным SCSI блоком запроса (SRB) и посылает запрос порт драйверу через фильтр драйверы нижнего уровня.

Порт-драйвер полученные пакеты SRB преобразует к формату для передачи по аппаратной шине, и посылает их адаптеру главной шины (HBA), через драйвер вводы вывода шины и один или несколько фильтр драйверов.

Благодаря тому, что виртуальный диск не является реальным физическим устройством, нам не требуется производить доступ к аппаратной шине и формировать специальные пакеты SRB. Данные в оперативной памяти уже доступны на уровне классового драйвера; нецелесообразно и не нужно передавать IRP пакеты на нижний уровень.

Таким образом, требуется разработать классовый драйвер, в который будет происходить вся обработка запросов и обращение к данным диска для нашего класса устройств виртуального диска.

1.5 Выбор файловой системы

Для того, чтобы начать работу с диском, диск разбивается на разделы. Раздел — это непрерывная часть физического диска, которую операционная система представляет пользователю как логическое устройство (используются также названия логический диск и логический раздел). Именно с логическими устройствами работает пользователь, обращаясь к ним по символьным именам, используя, например, обозначения А, В, С. В частном случае, когда все дисковое пространство охватывается одним разделом, логическое устройство представляет физическое устройство в целом.

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

На каждом логическом устройстве может создаваться только одна файловая система. Для дисковых накопителей Windows поддерживает файловые системы FAT и NTFS.

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

Отличительные свойства NTFS[2], то что она ориентирована для поддержки больших файлов, восстанавливаемости после сбоев и отказов программ и аппаратуры управления дисками – все это приводит к значительному размеру метаданных. Поэтому минимальный размер тома равен 10 Мб, а на практике использование NTFS оправдано для логических дисков от 400 Мб.

Файловая система FAT относится к ФС с глобальным индексом, и поэтому метаданные состоят из метки тома, глобальной таблицы диска и коневого каталога. Все остальное место свободное и отводится под создаваемые файлы и каталоги. Тот факт , что при каждой операции чтения/ записи идет обращение к таблице FAT не влияет на производительность, т.к. время доступа для оперативной памяти ничтожно мало по сравнению с жестким диском. Также существует несколько версия FAT: 12, 16 и 32. FAT 12 можно использовать на маленьких дисках от 1 Мб. Использование FAT 32 в основном предназначена для томов объемом в несколько Гб, и минимальный размер тома ограничен 512 Мб, этому она не подходит для виртуального диска.

Таким образом для нашего виртуального диска будет использоваться файловые системы FAT 12(когда объем диска не превышает 16 Мб) и FAT 16.

2. КОНСТРУКТОРСКИЙ РАЗДЕЛ

2.1 Структура классового драйвера

Драйвер реализуется как набор процедур, каждая из которых предназначена для реализации отдельного типа обращений к драйверу со стороны диспетчера ввода/вывода. Процедуры, которые необходимо поддерживать классовому драйверу приведены в таблице 1.

Выполняется при загрузке драйвера операционной системой. Здесь драйвер регистрирует свои остальные точки входа и выполняет свою общую инициализацию.

Вызывается при выгрузке драйвера. Здесь необходимо освободить все затребованные ресурсы.

Здесь создаётся объект-устройство, соответствующий полученному уведомлению от менеджера устройств, и выполняется инициализация данных, специфичных для данного устройства.

Выполняет обработку специфичных Plug&Play запросов , таких как инициализация устройства, таких как инициализация устройства, остановка, удаление устройства и обрабатывать остальные запроса

Выполняет обработку запросов по управлению питанием устройства

Обрабатывает запросы от подсистемы инструментария Windows (WMI)

Обслуживают запросы на чтение запись данных для устройства.

2.2 Организация внутреннего хранения данных диска

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

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

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

Следующим шагом выберем, каким образом мы зарезервируем память для диска. Для резервирования памяти в режиме ядра Windows предоставляет специальные системные вызовы. Существуют следующие типы резервируемой памяти:

· Страничная память(Paged memory) – виртуальная память, которая может быть перемещена системой на жесткий диск в любой момент времени. В случае, если приложение обратиться к отсутствующей в физической памяти области своей виртуальной памяти, то возникает исключение по отсутствию страницы в памяти. В результате системный обработчик перехватывает это исключение и загружает в физическую память отсутствующую страницу. Однако при работе в режиме ядра, когда уровень приоритета равен или выше DISPATCH_LEVEL, это исключение создаст ситуацию, когда системный обработчик не может подгрузить страницу т.к. его IRQL меньше текущего.

· Нестраничная память(Nonpaged memory) – эта память никогда не может быть перемещена системой на жесткий диск и всегда остается в физической оперативной памяти. В результате, обращаться к этой памяти можно при любом уровне IRQL. Объем данной памяти ограничен даже при наличии достаточного объема физической памяти в Windows 2000 660 Мбайтами, а в Windows XP 1300 Мбайтами.

Поскольку обращение к образу диска происходит при уровне привилегий PASSIVE_LEVEL или DISPATCH_LEVEL, но в особых ситуациях этот приоритет может быть выше. Поэтому во избежание возникновения ситуации, когда страница отсутствует в памяти, и мы ее не сможем подгрузить – виртуальный диск будет использовать нестраничную память. Дополнительно мы увеличим быстродействие драйвера, т.к. уже не требуется подгружать отсутствующие страницы с жесткого диска.

2.3 Доступ к передаваемым данным

Рассмотрим, каким образом драйвер может получить доступ к передаваемым данным. Пользовательский процесс, вызывая функцию API (например, WriteFile), передаёт ей указатель на буфер, в котором размещается записываемая информация. Однако, передаваемый виртуальный адрес действительно будет указывать на записываемую информацию только в контексте данного процесса. Операции же ввода/вывода в драйвере происходят в контексте произвольного процесса. Из-за смены таблиц страничного преобразования при переключении процессов использовать переданный виртуальный адрес в произвольном контексте совершенно недопустимо.

Для операций ввода/вывода архитектура операционной предусматривает два специальных метода передачи буфера данных, принадлежащего инициатору запроса:

· Буферизированный (buffered I/O). Драйверу в пакете запроса ввода/вывода передаётся указатель на копию исходного буфера в невыгружаемой памяти (поле AssociatedIrp.SystemBuffer). Подсистема ввода/вывода отвечает за точное соответствие содержимого этого буфера передаваемым данным. Этот метод, в основном, используется для устройств, не предающих больших объёмов данных: манипуляторы, низкоскоростные коммуникационные линии и т. п.

· Прямой (direct I/O). В этом случае система блокирует страницы пользовательского буфера, чтобы они не были выгружены на диск во время передачи данных. Расположение пользовательского буфера в физической памяти описывается структурой MDL (Memory Descriptor List), доступной в пакете запроса ввода/вывода через поле MdlAddress. По этой структуре необходимо настроить системную таблицу страниц на тот же буфер в физической памяти. Это осуществляется функцией MmGetSystem, которая возвращает виртуальный адрес буфера в системной области памяти. Данный метод эффективен с большими объёмами данных, например, при работе с дисковыми накопителями.

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

2.4 Обработка запросов Plug and Play

В процессе работы диспетчер ввода вывода может динамически управлять состоянием устройства: запускать, останавливать и выгружать. Реализация этих функций драйвером устройства хранения обеспечивает при обработке специфичных PnP IRP пакетов. В таблице 2 приведены описания IRP пакетов, которые должны поддерживаться.

Инициализация устройства с заданными ресурсами

Проверка осуществимости остановки устройства для перераспределения ресурсов

Остановка устройства с потенциальной возможность. перезапуска или удаления из системы

Уведомляет, что предыдущий запрос на остановку не получит дальнейшего развития

Проверка осуществимости безопасного удаления устройства

Выполнить безопасное удаление устройства

Уведомляет, что предыдущий запрос на удаление не получит дальнейшего развития

Уведомляет, что устройство было удалено без предварительного предупреждения

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

Основным состоянием диска будет WORKING – когда диск находится в рабочем состоянии. Остальные состояния(приведенные в таблице 3) носят информативный характер, чтобы узнать текущий режим работы диска. При операциях доступа к устройству будет осуществляться проверка состояния WORKING, и только при нем доступ к диску разрешен.

Илон Маск рекомендует:  Шаблон сайта экстрим HTML, CSS, JavaScripts, 5 страниц
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL
Название: Разработка драйвера виртуального жесткого диска
Раздел: Рефераты по информатике, программированию
Тип: курсовая работа Добавлен 05:26:00 18 июня 2009 Похожие работы
Просмотров: 1257 Комментариев: 14 Оценило: 3 человек Средний балл: 5 Оценка: неизвестно Скачать