Введение в драйверы устройств ввода/вывода. Лекция драйверы


Лекция - Драйверы и windows 2 страница

s5 — ``классическая'' ФС, сохранившаяся почти без измененийс самых ранних версий системы — s5, по-видимому, означаетUnix System 5. Ограничивает имя файла 14 символами.Неустойчива к сбоям.

ufs — файловая система, разработанная в университете Беркли, известная также как FFS (Fast File System) и Berkley FS.Является основной ФС в большинстве версий BSD UNIX и поддерживаетсямногими другими ОС семействаUnix.Имеет более высокую производительность, чем s5, в первую очередьза счет разбиения таблицы инодов и списка свободных блоковна участки (группы цилиндров). Такое разбиение уменьшаетперемещение головки дисковода при обращении к системным ипользовательским данным. Поддерживает дисковые квоты -ограничения на объем дискового пространства, занятого файламитого или иного пользователя.Ограничивает имя файла размером блока (обычно 512 символов).Неустойчива к сбоям.

bfs — Boot File System — загрузочная файловая система.Эта ФС имеет очень простую структуру, отчасти похожую на файловую системуRT-11: все файлы в ней обязаны занимать непрерывноепространство. Такая структура упрощает первичный загрузчик системы, которому теперь не нужно разбираться в каталогах и инодах.bfs имеет довольно низкую производительность и требует длительнойпроцедуры размонтирования, если в нее были записаны новые данные.Фактически, при таком размонтировании происходит операция сжатия ФС, эквивалентная команде SQEESE в RT-11. Используется дляхранения ядра системы, и нескольких конфигурационных файлов, используемыхпри загрузке. Все эти данные считываются только при загрузке системы иперезаписываются только при изменениях конфигурации ядра, поэтому высокаяпроизводительность от этой ФС не требуется.

vxfs — устойчивая к сбоям ФС Veritas с регистрациейнамерений.Версия, входящая в стандартную поставку системы, журналирует толькосистемные структуры данных.За отдельную плату можно приобрести ``продвинутую'' версиюVeritas, которая обеспечивает журналирование пользовательскихданных.

cdfs — Файловая система ???, используемая на CD-ROM.

nfs — Network File System — драйвер файловой системы, обеспечивающийразделение файлов с использованием сетевого протокола TCP/IP.Протокол NFS был предложен фирмой Sun Microsystemsв середине 80-х гг. и в настоящее время поддерживается практически всемичленами семейства Unix.NFS-клиенты и NFS-серверы реализованы также дляVMS, Windows NT, Novell Netware,OS/2, MacOS, MS/DR DOS иWindows 3.x/95.

rfs — Remote File Sharing — использование удаленной UNIX-системы вкачестве файлового сервера. Этот протокол был разработан фирмойAT&T в 80-е гг. и пригоден только для соединения системUNIX System V.

nucfs — NetWare Unix Client File System. Этот драйвер предназначендля присоединения к файловым серверам Novell Netware. Он входитв состав системы UnixWare, поставляемой фирмой SCO, но не в остальные версии UNIX SVR4.

Любопытно, что даже MS/DR DOS версий выше 3.30 имеют возможностьустанавливать драйвер файловой системы. Такой драйвер может быть реализованпутем перехвата недокументированных функций прерывания 0x2F -группы функций ``Network Redirector'' и ``IFS''. Таким образом реализованряд сетевых клиентов для MS/DR DOS.К сожалению, авторы не смогли найти полноценного описания этих функций.

 

33. Файловая система FATхх. Назначение и организация таблицы распределения файлов. Типы записей в FAT.

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

Том, отформатированный для использования файловой системы FAT, размечается по кластерам. Размер кластера по умолчанию определяется размером тома. При использовании файловой системы FAT номер кластера должен иметь длину не более 16 бит и представлять собой одну из степеней 2. Размеры кластеров по умолчанию в зависимости от размера тома приведены в таблице. При форматировании тома FAT с помощью программы Format из командной строки пользователь имеет возможность указать другой размер кластера, отличный от значения, устанавливаемого по умолчанию. Однако устанавливаемый размер не может быть меньше размера по умолчанию, указанного в таблице для соответствующего размера тома.

Таблицы расположения файлов (области FAT1 и FAT2) содержат следующую информацию о каждом кластере тома:

— Unused (кластер не используется)

— Cluster in use by a file (кластер используется файлом)

— Bad cluster (плохой кластер)

— Last cluster in a file (последний кластер файла)

Корневой каталог содержит записи для каждого файла и каждого каталога, расположенных в корневом каталоге. Единственным различием между корневым каталогом и всеми остальными каталогами является то, что корневой каталог занимает четко определенное место на диске и имеет фиксированный размер (512 записей для жесткого диска; для дискет этот размер определяется объемом дискеты).

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

— имя (в формате «8+3»),

— байт атрибутов (8 бит),

— время создания (24 бит),

— дата создания (16 бит),

— дата последнего доступа (16 бит),

— время последней модификации (16 бит),

— дата последней модификации (16 бит),

— номер начального кластера файла в таблице расположения файлов (16 бит),

— размер файла (32 бит).

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

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

Файл FAT имеет 4 атрибута, которые могут сбрасываться и устанавливаться пользователем:

— archive file (архивный файл),

— system file (системный файл),

— hidden file (скрытый файл),

— read-only file (файл только для чтения).

Доступ к файлам, хранящимся на томах, использующих файловую систему FAT, может быть осуществлен, если компьютер работает под управлением одной из следующих операционных систем: MS DOS, Windows 95, Windows NT, OS/2.

Ограничение системы FAT на размер логического диска составляет 2 Gb. При этом каждая запись FAT (на разделах объемом более 16 Mb) является 2-байтовым числом, следовательно, на логическом разделе может быть не более 65536 кластеров. Поэтому на дисках объемом более 1 Gb размер кластера в системе FAT составляет 32 K, т.е. «хвост» (slack) каждого файла занимает от 0 до 32 К, из чего следует, что каждая тысяча файлов поглощает в среднем 16 Mb дискового пространства. Файловую систему FAT, вследствие больших накладных расходов памяти, не рекомендуется использовать для томов, размер которых превышает 511 Mb.

 

34. Структура элемента каталога в файловой системе FATхх. Опорные и дополнительные элементы. Метка тома.

При создании каталога для него «пожизненно» выставляется DIR_FileSize = 0. Размер содержимого каталога определяется простым следованием по цепочкам кластеров до метки End Of Chain. Размер самого каталога лимитируется файловой системой в 65 535 32-байтных записей (т.е. записи каталога в таблице FAT не могут занимать более 2Мб). Это ограничение призвано ускорить операции с файлами и позволить различным служебным программам использовать 16 битное целое (WORD) для подсчета количества записей в директории. (Как следствие, возникает теоретическое ограничение на количество файлов в каталоге – 65 535 при условии, что все имена файлов следуют стандарту 8.3). Каталогу отводится один кластер области данных (за исключением случая, если это корневой каталог FAT12/FAT16) и полям DIR_FstClusHI / DIR_FstClusLO присваивается значение номера этого кластера. В таблицу FAT для записи, соответствующей этому кластеру, помещается метка EOC, а сам кластер забивается нулями. Далее создаются два специальных файла, без которых директория FAT считается поврежденной (первые две 32-байтных записи в области данных кластера) – файлы нулевого размера “dot” (идентификатор каталога) и “dotdot” (указатель на родительский каталог) с именами “.” (точка) и “..” (две точки) соотв. Штампы даты-времени этих файлов приравниваются значениям для самого каталога на момент создания и не обновляются при изменениях каталога. Поля DIR_FstClusHI / DIR_FstClusLO файла «.» содержат значение номера содержащего его кластера, а файла «..» – номера первого кластера каталога, содержащего данный. Таким образом, файл «.» отсылает к самому каталогу, а файл «..» – к начальному кластеру родительского каталога; если родительский каталог – корневой, начальным кластером считается нулевой.

FAT16 и FAT32 имеют очень компактные каталоги, размер каждой записи которых предельно мал. Более того, из-за сложившейся исторически системы хранения длинных имен файлов (более 11 символов), в каталогах систем FAT используется не очень эффективная и на первый взгляд неудачная, но зато очень экономная структура хранения этих самих длинных имен файлов. Работа с каталогами FAT производится достаточно быстро, так как в подавляющем числе случаев каталог (файл данных каталога) не фрагментирован и находится на диске в одном месте.

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

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

Информация папок используется операционными системами, поддерживающими файловую систему FAT. Кроме того, Windows 2000 может хранить в записи папки дополнительную временную информацию (time stamps). Эти дополнительные временные атрибуты указывают, когда файл был создан и когда к нему в последний раз предоставлялся доступ. Главным образом, дополнительные атрибуты используются приложениями POSIX.

В файловых системах FAT32 и VFAT (виртуальная FAT, расширение FAT16) включена поддержка длинных имен файлов (long file name, LFN). Для хранения длинного имени используются элементы каталога, смежные с основным элементом. Имя файла записывается не ASCII-символами, а в Unicode. В одном элементе каталога можно сохранить фрагмент длиной до 13 символов Unicode. Неиспользованный участок последнего фрагмента заполняется кодами 0xFFFF. Структура элемента каталога для длинного имени файла представлена в таблице 2.

Каталоги. Для каждого файла на диске имеется один элемент в определенном каталоге. Один элемент основного каталога выделяется для метки диска (метки тома). Для каждого каталога имеется элемент в его родительском каталоге. Кроме того, каждый каталог, за исключением основного, содержит по одному элементу для специальных имен "." и "..". Эти элементы указывают начало цепочки в FAT соответственно для каталога и для его родительского каталога. Так в общем случае каждый каталог описан в нескольких местах: в родительском каталоге, в самом себе и в каждом из его подчиненных каталогов. каждый элемент каталога имеет длину 32 байта и состоит из 8 полей.

Поле 1: Имя файла Длина поля — 8 байтов. Если имя файла содержит меньше 8 символов, поле дополняется справа пустыми позициями. Имя файла записывается в каталоге прописными буквами. Первый байт поля используется для обозначения трех специальных случаев:

1. Значение OOH и первом байте показывает, что этот элемент каталога никогда не был использован.

2. При стирании файла MS DOS записывает E5H в первом байте соответствующего элемента каталога.

3. Значение 2EH в первом байте показывает, что этот элемент служит для описания самого каталога.

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

Поле 3: Атрибуты файла Каждый бит задает определенный атрибут файла. Бит 0: только для чтения. При значении 1 из файла можно читать, но в него нельзя писать и его нельзя стереть.

Бит 1: Скрытый. При значении 1 файл невидим для обычных операций(DIR, DEL).

Бит 2: Системный. Имеет эффект бита 1. Не имеет особого смысла в DOS.

Бит 3: Метка тома. При зна чении 1 обозначает элемент каталога какметку тома. Метка записывается в поля 1(имя) и 2(суффикс) и содержит не более 11 символов.

Бит 4: Каталог. При значении 1 идентифицирует файл как каталог.

Бит 5: Архивный. Обнуляется всегда, когда файл аривируется командой MS DOS BACKUP.

Поле 4: Резервировано. Имеет длину 10 байтов. Резервировано для будущих расширении DOS.

Поле 5: Время. Имеет длину 2 байта. Содержит время создания или последнего изменения файла.

Поле 6: Дата. Имеет длину 2 байта. Содержит дату создания или последнего изменения файла.

Поле 7: Номер первого кластера. Имеет длину 2 байта. Служит указателем к первому из кластеров файла в области для данных и одновременно указывает начало цепочки элементов FAT для этого файла.

Поле 8: Размер файла. Имеет длину 4 байта — здесь можно записать достаточно большое число, так что размер дисковой памяти остается единственным ограничением для размера файла.

 

35. Поддержка и внутренняя организация длинных имен в ОС Windows для файловых систем FATxx. Псевдоним длинного имени в пространстве имен DOS.

Для представления длинного имени в FAT32 стали использовать элементы каталога, в том числе и корневого, поэтому количество файлов увеличили с 512 до2048. Длинное имя разрезано на несколько стандартных описателей (по 13 букв на один описатель), каждый из которых содержит атрибут метки тома (чтобы их не было видно в DOS), плюс один нормальный описатель с укороченным именем (именно его видно в DOS). Буквы имени записываются в кодировке Unicode (по 2 байта на символ), причем точка и завершающий ноль также пишутся. Если длина имени кратна 13 символам, то нулевой символ не записывается. Остаток описателя дополняется кодами 0FFFFh. Участки записываются от последнего к первому, сразу за ними следует стандартный описатель. Нумеруются они с 1, причём у последнего участка установлен бит 6 в номере участка.

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

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

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

 

 

36. Система операций над файлами. Типы доступа к данным файла. Защита файлов и данных в ОС. Обеспечение целостности FS. Восстанавливаемость после сбоев ОС и аппаратуры.

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

Общие операции над файлами можно разделить на три группы:

1) операции над файлами как над единым целым;

2) операции для обмена данными между файлом и программой, инициирующей обмен;

3) служебные операции.

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

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

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

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

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

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

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

Для восстановления испорченных файлов и каталогов обычно применяют специальную утилиту для проверки и восстановления целостности файловой системы (например, chkdsk для Windows или fsck для Unix и Linux). Однако эти утилиты имеют два серьезных недостатка: 1) они проверяют только структуру файловой системы и метаданные; 2) для их выполнения требуется много времени, а также монопольный доступ к файловой системе (как правило, сразу после загрузки системы).

Для решения такого рода проблем компания QNX Software Systems предложила новую, защищенную от сбоев электропитания файловую систему. Используя технологии, изначально разработанные для корпоративных информационных систем, и оптимизировав их для встраиваемых систем с ограниченными ресурсами, компания QNX создала инновационную файловую систему на основе технологии копирования при записи (copy-on-write), которая позволяет обеспечить целостность данных.

37. Файловая система NTFS. Основные свойства и возможности. Обеспечение целостности и отказоустойчивости NTFS. Управление доступом к данным и защита данных в NTFS.

NTFS (от англ. New Technology File System — «файловая система новой технологии») — стандартная файловая система для семейства операционных систем Microsoft Windows NT.

NTFS поддерживает систему метаданных и использует специализированные структуры данных для хранения информации о файлах для улучшения производительности, надёжности и эффективности использования дискового пространства. NTFS хранит информацию о файлах в главной файловой таблице — Master File Table (MFT). NTFS имеет встроенные возможности разграничения доступа к данным для различных пользователей и групп пользователей (списки контроля доступа — Access Control Lists (ACL)), а также назначать квоты (ограничения на максимальный объём дискового пространства, занимаемый теми или иными пользователями). NTFS использует систему журналирования USN для повышения надёжности файловой системы.

NTFS разработана на основе файловой системы HPFS (от англ. High Performance File System — высокопроизводительная файловая система), создававшейся Microsoft совместно с IBM для операционной системы OS/2. Но, получив такие несомненно полезные новшества, как квотирование, журналируемость, разграничение доступа и аудит, в значительной степени утратила присущую прародительнице (HPFS) весьма высокую производительность файловых операций.

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

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

38. Внутренняя организация NTFS на логическом томе. Метафайлы и их назначение. Структура главной таблицы файлов (МFТ).

Структура файловой системы. Как и любая другая система, NTFS делит все полезное пространство диска на кластеры — блоки данных, используемые единовременно. NTFS поддерживает различные размеры кластеров — от 512 байт до 64 Кбайт, стандартом считается кластер размером 4 Кбайт.

Диск NTFS условно делится на две части. Первые 12 % диска отводятся под так называемую MFT-зону — пространство, в котором размещен метафайл MFT (Master File Table). Запись каких-либо данных в эту область невозможна-MFT-зона всегда держится пустой — это делается для того, что бы главный служебный файл (MFT) не фрагментировался при своем расширении. Остальные 88 % диска представляют собой пространство для размещения файлов.

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

Метафайл (англ. Metafile) — это общий термин для формата файлов, который может дополнительно хранить в себе и данные (доп. сведения) о хранимых в нём (файле) данных — сведения, которые в обычном режиме просмотра содержимого сокрыты от пользователя.

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

В графических файлах — дополнительная неграфическая информация о дате создания, применённых инструментах и их данных, также водяной знак;

В аудиофайлах — информация об исполнителе, дате записи, битрейте, жанре и тд.

Структура MFT. Каждый элемент файловой системы NTFS представляет собой файл, даже служебная информация. Как уже говорилось, главный файл NTFS называется MFT, или Master File Table — общая таблица файлов, которая размещается в MFT-зоне и представляет собой централизованный каталог всех остальных файлов диска. MFT поделен на записи фиксированного размера (обычно 1 Кбайт), и каждая запись соответствует какому-либо файлу. Первые 16 файлов носят служебный характер и недоступны операционной системе — они называются метафайлами, причем самый первый из них — сам MFT. Эти первые 16 элементов MFT — единственная часть диска, имеющая фиксированное положение. Остальная часть MFT-файла может сполагаться, как и любой другой файл, в произвольных местах иска — восстановить его положение можно с помощью его самого, используя за основу первый элемент MFT.

www.ronl.ru

НОУ ИНТУИТ | Лекция | Введение в драйверы устройств ввода/вывода

Аннотация: В данной лекции основное внимание уделяется драйверам устройств ввода/вывода. Приводятся практические примеры и задачи для самостоятельного рассмотрения.

Эта телефонная система LG Electronics Voice over IP (VoIP) основывается на Windows Embedded CE. Фотография с разрешения Mike Hall.

Введение в драйверы устройств В/В

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

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

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

Таблица 9.1. Библиотеки драйверов устройств CE Библиотека Описание
Собственные библиотеки микропроцессора Драйверы устройств для тесной интеграции собственных периферийных устройств микропроцессора. Например, микропроцессор ARM, и его дополнительная микросхема интегрирует многие периферийные устройства микропроцессора, такие как LCD, последовательный порт, USB Host, функцию USB, и т.д. SDB или аппаратная платформа, которая использует специальный микропроцессор будут использовать то же самое множество собственных драйверов микропроцессора. В Windows Embedded CE большинство микропроцессоров являются высоко интегрированными микропроцессорами, которые содержат много собственной периферии. Они связаны с так называемыми драйверами SOC (система-на-микросхеме) и находятся в ..\WINCE600 \Platform\Common\Src\SOC.
Специфические для микропроцессора библиотеки поддержки OAL Функции OAL для устройств, таких как часы реального времени, таймер, и контроллер отладки Ethernet, который обычно присутствует в микропроцессоре. Эта библиотека минимизирует написанный код OAL. Они также называются драйверами SOC (система-на-микросхеме) и находятся в ..\WINCE600 \Platform\Common\Src\SOC.
BSP или драйверы специфические для аппаратной платформы Драйверы устройств для периферии, которые являются специфическими для заданного SDB или аппаратной платформы. Эти драйверы имеют специфический для аппаратной платформы код и могут использоваться только на этой аппаратной платформе. Эти драйверы находятся в ..\WINCE600\Platform\<Hardware Platform Name> \Src\Drivers.
Другие распространенные драйверы периферийных устройств Драйверы для стратегических периферийных наборов микросхем, которые обычно встречаются во многих SDB или конструкциях аппаратных платформ. Сюда входят такие устройства как Realtek RTL8139, базовый NE2000, наборы микросхем DEC/Intel 2114x Ethernet, MediaQ MQ200, наборы микросхем дисплея ATI Rage XL, и наборы микросхем аудио Ensoniq. Цель состоит в том, чтобы предоставить драйверы производственного качества для 50% стратегических наборов микросхем, которые покрывают более 75% аппаратных платформ, доступных на рынке. Они называются общими драйверами и находятся в . .\WINCE600\Public\Common\Oak\Drivers. Исходный код для модулей находится в каталоге Public.
Модель потокового интерфейса для драйверов устройств

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

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

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

Сами функции потокового интерфейса создаются таким образом, чтобы как можно ближе соответствовать семантике обычных интерфейсов прикладного программирования (API) файловых систем, таких как CreateFile, WriteFile, ReadFile, IOControl, и CloseHandle. В качестве побочного эффекта такого дизайна устройства, которые управляются потоковым интерфейсом, доступны для приложений через файловую систему; приложения взаимодействуют с драйвером, открывая специальные файлы в файловой системе.

Драйверы потокового интерфейса могут иметь монолитную архитектуру или архитектуру с двумя слоями, MDD и PDD, как показано на рисунке 9.1.

Две альтернативные архитектуры драйвера потокового интерфейса. Монолитный драйвер потокового интерфейса или Разделенный на слои драйвер потокового интерфейса. В разделенной на слои архитектуре драйвера в CE два слоя называются MDD и PDD Рис. 9.1. Две альтернативные архитектуры драйвера потокового интерфейса. Монолитный драйвер потокового интерфейса или Разделенный на слои драйвер потокового интерфейса. В разделенной на слои архитектуре драйвера в CE два слоя называются MDD и PDD

Интерпретация устройств как специальных файлов распространена во многих операционных системах, включая настольные версии Microsoft Windows и даже первые версия Unix. Там устройства печати традиционно представлялись именами специальных файлов LPTx:, а последовательные порты именами специальных файлов COMx:, и т.д.

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

В некоторых менее распространенных случаях драйверы потокового интерфейса могут переупаковывать существующие ресурсы, обычно таким образом, который специфические приложения смогут более легко использовать. Например, такой тип драйвера потокового интерфейса может управлять приемником системы глобального позиционирования (GPS) с последовательным интерфейсом. В этом примере ISV может выбрать создание специального драйвера потокового интерфейса для работы в соединении с приложением отображения GPS. Многие приемники GPS соединяются с последовательными портами. Приложение отображения GPS может, поэтому, открыть специальный файл COMx:, соответствующий последовательному порту и непосредственно взаимодействовать с приемником GPS.

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

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

Все драйверы потоковых интерфейсов, управляют ли они встроенными устройствами или устанавливаемыми устройствами, загружаются ли они во время начальной загрузки или загружаются динамически, имеют похожие взаимодействия с другими системными компонентами. Рисунок 9.2 показывает архитектуру драйверов потокового интерфейса для встроенных устройств, которые загружаются Device Manager во время начальной загрузки.

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

Можно реализовать драйвер только с точками входа Init и Deinit и без префикса устройства. Невозможно получить доступ к этому драйверу с помощью CreateFile. PCIBUS и RegEnum являются двумя примерами такого типа драйвера. Эти драйверы находятся в каталогах ..\WINCE600\Public\Common\OAK\Drivers\PCIbus и ..\WINCE600\Public\Common\ OAK\Drivers\RegEnum.

Архитектура потокового интерфейса Рис. 9.2. Архитектура потокового интерфейса

Если DEVFLAGS_NAKEDENTRIES определен в подключе реестра Flags драйвера, то имена точек входа могут быть лишены отличий; например, Open, Close, и т. д. Пример драйвера батареи, который находится в ..\WINCE600\Public\Common\OAK\Drivers\Battdrvr, является примером драйвера, который использует точки входа без отличий. Настройки реестра драйвера батареи должны тем не менее включать префикс.

Реализации этих точек входа должны объявляться для экспорта из DLL, размещая __declspec(dllexport) перед объявлением функции. При разработке в C++, точки входа должны также объявляться как внешние "C".

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

Таблица 9.2. Функции драйвера потокового интерфейса. Программный элемент Описание
XXX_Close Эта функция закрывает контекст устройства, определенный hOpenContext. Эта функция требуется для доступа к устройству с помощью CreateFile. Если вы реализуете XXX_Close, вы должны реализовать XXX_Open.
XXX_Deinit Эта функция де-инициализирует устройство. Ее вызывает Device Manager. Эта функция требуется драйверам, загружаемым ActivateDeviceEx, ActivateDevice, или RegisterDevice.
XXX_Init Эта функция инициализирует устройство. Ее вызывает Device Manager. Эта функция требуется драйверам, загружаемым ActivateDeviceEx, ActivateDevice, или RegisterDevice.
XXX_IOControl Эта функция посылает команду на устройство. Эта функция может требоваться или нет, в зависимости от возможностей устройства, которые предоставляет драйвер. Эта функция требует реализации XXX_Open и XXX_Close.
XXX_Open Эта функция открывает устройство для чтения, записи, или того и другого. Приложение неявно вызывает эту функцию, когда вызывает CreateFile для получения указателя на устройство. Эта функция требуется для доступа к устройству с помощью CreateFile.
XXX_PowerDown Не обязательная. Эта функция выключает питание устройства. Она будет полезна только с устройствами, которые можно выключить с помощью программного управления.
XXX_PowerUp Не обязательная. Эта функция восстанавливает питание в устройстве.
XXX_PreClose Не обязательная. Эта функция помечает закрывающий указатель как недействительный, и пробуждает все спящие потоки.
XXX_PreDeinit Эта функция помечает экземпляр устройства как недействительный и пробуждает спящие потоки. Эта функция требуется, если реализована функция XXX_PreClose.
XXX_Read Эта функция считывает данные из устройства, идентифицированного открытым контекстом. Эта функция может требоваться или нет, в зависимости от возможностей устройства, которые предоставляет драйвер. Эта функция требует реализации XXX_Open и XXX_Close.
XXX_Seek Эта функция перемещает указатель данных в устройстве. Эта функция может требоваться или нет, в зависимости от возможностей устройства, которые предоставляет драйвер. Эта функция требует реализации XXX_Open и XXX_Close.
XXX_Write Эта функция записывает данные в устройство. Эта функция может требоваться или нет, в зависимости от возможностей устройства, которые предоставляет драйвер. Эта функция требует реализации XXX_Open и XXX_Close.

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

Чтобы реализовать множественный доступ, каждый вызов функции XXX_Open должен возвращать различное значение для hOpenContext. Драйвер устройства должен отслеживать, какие возвращаемые значения из XXX_Open используются. Последующие обращения к XXX_Close, XXX_Read, XXX_Write, XXX_Seek, и XXX_IOControl передают эти значения назад драйверу устройства, позволяя драйверу идентифицировать, какими внутренними структурами данных манипулировать.

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

www.intuit.ru

НОУ ИНТУИТ | Лекция | Введение в драйверы устройств ввода/вывода

Аннотация: В данной лекции основное внимание уделяется драйверам устройств ввода/вывода. Приводятся практические примеры и задачи для самостоятельного рассмотрения.

Эта телефонная система LG Electronics Voice over IP (VoIP) основывается на Windows Embedded CE. Фотография с разрешения Mike Hall.

Введение в драйверы устройств В/В

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

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

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

Таблица 9.1. Библиотеки драйверов устройств CE Библиотека Описание
Собственные библиотеки микропроцессора Драйверы устройств для тесной интеграции собственных периферийных устройств микропроцессора. Например, микропроцессор ARM, и его дополнительная микросхема интегрирует многие периферийные устройства микропроцессора, такие как LCD, последовательный порт, USB Host, функцию USB, и т.д. SDB или аппаратная платформа, которая использует специальный микропроцессор будут использовать то же самое множество собственных драйверов микропроцессора. В Windows Embedded CE большинство микропроцессоров являются высоко интегрированными микропроцессорами, которые содержат много собственной периферии. Они связаны с так называемыми драйверами SOC (система-на-микросхеме) и находятся в ..\WINCE600 \Platform\Common\Src\SOC.
Специфические для микропроцессора библиотеки поддержки OAL Функции OAL для устройств, таких как часы реального времени, таймер, и контроллер отладки Ethernet, который обычно присутствует в микропроцессоре. Эта библиотека минимизирует написанный код OAL. Они также называются драйверами SOC (система-на-микросхеме) и находятся в ..\WINCE600 \Platform\Common\Src\SOC.
BSP или драйверы специфические для аппаратной платформы Драйверы устройств для периферии, которые являются специфическими для заданного SDB или аппаратной платформы. Эти драйверы имеют специфический для аппаратной платформы код и могут использоваться только на этой аппаратной платформе. Эти драйверы находятся в ..\WINCE600\Platform\<Hardware Platform Name> \Src\Drivers.
Другие распространенные драйверы периферийных устройств Драйверы для стратегических периферийных наборов микросхем, которые обычно встречаются во многих SDB или конструкциях аппаратных платформ. Сюда входят такие устройства как Realtek RTL8139, базовый NE2000, наборы микросхем DEC/Intel 2114x Ethernet, MediaQ MQ200, наборы микросхем дисплея ATI Rage XL, и наборы микросхем аудио Ensoniq. Цель состоит в том, чтобы предоставить драйверы производственного качества для 50% стратегических наборов микросхем, которые покрывают более 75% аппаратных платформ, доступных на рынке. Они называются общими драйверами и находятся в . .\WINCE600\Public\Common\Oak\Drivers. Исходный код для модулей находится в каталоге Public.
Модель потокового интерфейса для драйверов устройств

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

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

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

Сами функции потокового интерфейса создаются таким образом, чтобы как можно ближе соответствовать семантике обычных интерфейсов прикладного программирования (API) файловых систем, таких как CreateFile, WriteFile, ReadFile, IOControl, и CloseHandle. В качестве побочного эффекта такого дизайна устройства, которые управляются потоковым интерфейсом, доступны для приложений через файловую систему; приложения взаимодействуют с драйвером, открывая специальные файлы в файловой системе.

Драйверы потокового интерфейса могут иметь монолитную архитектуру или архитектуру с двумя слоями, MDD и PDD, как показано на рисунке 9.1.

Две альтернативные архитектуры драйвера потокового интерфейса. Монолитный драйвер потокового интерфейса или Разделенный на слои драйвер потокового интерфейса. В разделенной на слои архитектуре драйвера в CE два слоя называются MDD и PDD Рис. 9.1. Две альтернативные архитектуры драйвера потокового интерфейса. Монолитный драйвер потокового интерфейса или Разделенный на слои драйвер потокового интерфейса. В разделенной на слои архитектуре драйвера в CE два слоя называются MDD и PDD

Интерпретация устройств как специальных файлов распространена во многих операционных системах, включая настольные версии Microsoft Windows и даже первые версия Unix. Там устройства печати традиционно представлялись именами специальных файлов LPTx:, а последовательные порты именами специальных файлов COMx:, и т.д.

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

В некоторых менее распространенных случаях драйверы потокового интерфейса могут переупаковывать существующие ресурсы, обычно таким образом, который специфические приложения смогут более легко использовать. Например, такой тип драйвера потокового интерфейса может управлять приемником системы глобального позиционирования (GPS) с последовательным интерфейсом. В этом примере ISV может выбрать создание специального драйвера потокового интерфейса для работы в соединении с приложением отображения GPS. Многие приемники GPS соединяются с последовательными портами. Приложение отображения GPS может, поэтому, открыть специальный файл COMx:, соответствующий последовательному порту и непосредственно взаимодействовать с приемником GPS.

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

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

Все драйверы потоковых интерфейсов, управляют ли они встроенными устройствами или устанавливаемыми устройствами, загружаются ли они во время начальной загрузки или загружаются динамически, имеют похожие взаимодействия с другими системными компонентами. Рисунок 9.2 показывает архитектуру драйверов потокового интерфейса для встроенных устройств, которые загружаются Device Manager во время начальной загрузки.

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

Можно реализовать драйвер только с точками входа Init и Deinit и без префикса устройства. Невозможно получить доступ к этому драйверу с помощью CreateFile. PCIBUS и RegEnum являются двумя примерами такого типа драйвера. Эти драйверы находятся в каталогах ..\WINCE600\Public\Common\OAK\Drivers\PCIbus и ..\WINCE600\Public\Common\ OAK\Drivers\RegEnum.

Архитектура потокового интерфейса Рис. 9.2. Архитектура потокового интерфейса

Если DEVFLAGS_NAKEDENTRIES определен в подключе реестра Flags драйвера, то имена точек входа могут быть лишены отличий; например, Open, Close, и т. д. Пример драйвера батареи, который находится в ..\WINCE600\Public\Common\OAK\Drivers\Battdrvr, является примером драйвера, который использует точки входа без отличий. Настройки реестра драйвера батареи должны тем не менее включать префикс.

Реализации этих точек входа должны объявляться для экспорта из DLL, размещая __declspec(dllexport) перед объявлением функции. При разработке в C++, точки входа должны также объявляться как внешние "C".

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

Таблица 9.2. Функции драйвера потокового интерфейса. Программный элемент Описание
XXX_Close Эта функция закрывает контекст устройства, определенный hOpenContext. Эта функция требуется для доступа к устройству с помощью CreateFile. Если вы реализуете XXX_Close, вы должны реализовать XXX_Open.
XXX_Deinit Эта функция де-инициализирует устройство. Ее вызывает Device Manager. Эта функция требуется драйверам, загружаемым ActivateDeviceEx, ActivateDevice, или RegisterDevice.
XXX_Init Эта функция инициализирует устройство. Ее вызывает Device Manager. Эта функция требуется драйверам, загружаемым ActivateDeviceEx, ActivateDevice, или RegisterDevice.
XXX_IOControl Эта функция посылает команду на устройство. Эта функция может требоваться или нет, в зависимости от возможностей устройства, которые предоставляет драйвер. Эта функция требует реализации XXX_Open и XXX_Close.
XXX_Open Эта функция открывает устройство для чтения, записи, или того и другого. Приложение неявно вызывает эту функцию, когда вызывает CreateFile для получения указателя на устройство. Эта функция требуется для доступа к устройству с помощью CreateFile.
XXX_PowerDown Не обязательная. Эта функция выключает питание устройства. Она будет полезна только с устройствами, которые можно выключить с помощью программного управления.
XXX_PowerUp Не обязательная. Эта функция восстанавливает питание в устройстве.
XXX_PreClose Не обязательная. Эта функция помечает закрывающий указатель как недействительный, и пробуждает все спящие потоки.
XXX_PreDeinit Эта функция помечает экземпляр устройства как недействительный и пробуждает спящие потоки. Эта функция требуется, если реализована функция XXX_PreClose.
XXX_Read Эта функция считывает данные из устройства, идентифицированного открытым контекстом. Эта функция может требоваться или нет, в зависимости от возможностей устройства, которые предоставляет драйвер. Эта функция требует реализации XXX_Open и XXX_Close.
XXX_Seek Эта функция перемещает указатель данных в устройстве. Эта функция может требоваться или нет, в зависимости от возможностей устройства, которые предоставляет драйвер. Эта функция требует реализации XXX_Open и XXX_Close.
XXX_Write Эта функция записывает данные в устройство. Эта функция может требоваться или нет, в зависимости от возможностей устройства, которые предоставляет драйвер. Эта функция требует реализации XXX_Open и XXX_Close.

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

Чтобы реализовать множественный доступ, каждый вызов функции XXX_Open должен возвращать различное значение для hOpenContext. Драйвер устройства должен отслеживать, какие возвращаемые значения из XXX_Open используются. Последующие обращения к XXX_Close, XXX_Read, XXX_Write, XXX_Seek, и XXX_IOControl передают эти значения назад драйверу устройства, позволяя драйверу идентифицировать, какими внутренними структурами данных манипулировать.

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

www.intuit.ru

Лекция 14

ЛЕКЦИЯ 14

Управление вводом-выводом

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

Физическая организация устройств ввода-вывода.

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

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

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

ОС выполняет ввод-вывод, записывая команды в регистры контроллера. Например, контроллер гибкого диска IBM PC принимает 15 команд, таких как READ, WRITE, SEEK, FORMAT и т.д. Когда команда принята, процессор оставляет контроллер и занимается другой работой. При завершении команды контроллер организует прерывание для того, чтобы передать управление процессором операционной системе, которая должна проверить результаты операции. Процессор получает результаты и статус устройства, читая информацию из регистров контроллера.

Организация программного обеспечения ввода-вывода.

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

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

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

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

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

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

Для решения поставленных проблем целесообразно разделить программное обеспечение ввода-вывода на четыре слоя (рисунок 1):

• Обработка прерываний,

• Драйверы устройств,

• Независимый от устройств слой операционной системы,

• Пользовательский слой программного обеспечения.

Рис.1

Обработка прерываний.

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

Драйверы устройств.

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

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

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

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

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

Независимый от устройств слой операционной системы.

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

Типичными функциями для независимого от устройств слоя являются:

• обеспечение общего интерфейса к драйверам устройств,

• именование устройств,

• защита устройств,

• обеспечение независимого размера блока,

• буферизация,

• распределение памяти на блок-ориентированных устройствах,

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

• уведомление об ошибках.

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

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

Пользовательский слой программного обеспечения.

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

count = write (fd, buffer, nbytes),

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

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

studfiles.net


Смотрите также