Драйверы ввода вывода это
Первоначально термин «драйвер» применялся в достаточно узком смысле: под драйвером понимался программный модуль, который:
· входит в состав ядра операционной системы, работая в привилегированном режиме;
· непосредственно управляет внешним устройством, взаимодействуя с его контроллером с помощью команд ввода-вывода компьютера;
· обрабатывает прерывания от контроллера устройства;
· предоставляет прикладному программисту удобный логический интерфейс работы с устройством, экранируя от него низкоуровневые детали управления устройством и организации его данных;
· взаимодействует с другими модулями ядра ОС с помощью строго оговоренного интерфейса, описывающего формат передаваемых данных, структуру буферов, способы включения драйвера в состав ОС, способы вызова драйвера, набор общих процедур подсистемы ввода-вывода, которыми драйвер может пользоваться, и т. п.
Согласно этому определению драйвер вместе с контроллером устройства и прикладной программой воплощали идею многослойного подхода к организации программного обеспечения. Контроллер представлял нижний слой управления устройством, выполняющий операции в терминах блоков и агрегатов устройства (например, передвижение головки дисковода, побитную передачу байта по двухпроводному кабелю). Драйвер выполнял более сложные операции, преобразуя, например, данные, адресуемые в терминах номеров цилиндров, головок и секторов диска, в линейную последовательность блоков или устанавливая логическое соединение между двумя модемами через телефонную сеть. В результате прикладная программа уже работала с данными, преобразованными в достаточно понятную для человека форму, – файлами, таблицами баз данных, текстовыми окнами на мониторе и т. п., не вдаваясь в детали представления этих данных в устройствах ввода-вывода. Кроме того, помещение драйвера в привилегированный режим и запрет для пользовательских процессов выполнять операции ввода-вывода защищают критически важные для работы самой ОС устройства ввода-вывода от ошибок прикладных программ, а также позволяют ОС надежно контролировать процесс разделения устройств и их данных между пользователями и процессами.
В описанной схеме драйверы не делились на слои. При этом они выполняли задачи разного уровня сложности: как самые примитивные, например, просто последовательно передавали контроллеру байты для дальнейшего использования, так и достаточно сложные, связанные с отработкой протокола взаимодействия между модемами или вычерчиванием на экране математических кривых.
Постепенно, по мере развития операционных систем и усложнения структуры подсистемы ввода-вывода, наряду с традиционными драйверами в операционных системах появились так называемые высокоуровневые драйверы, которые располагаются в общей модели подсистемы ввода-вывода над традиционными драйверами. Появление высокоуровневых драйверов можно считать дальнейшим развитием идеи многослойной организации подсистемы ввода-вывода. Вместо того чтобы концентрировать все функции по управлению устройством в одном программном модуле, во многих случаях гораздо эффективней распределить их между несколькими модулями в соседних слоях иерархии. Традиционные драйверы которые стали называть аппаратнымидрайверами, низкоуровневыми драйверами, или драйверами устройств, подчеркивая их непосредственную связь с управляемым устройством, освобождаются от высокоуровневых функций и занимаются только низкоуровневыми операциями. Эти низкоуровневые операции составляют фундамент, на котором можно построить тот или иной набор операций вдрайверах более высоких уровней.
При таком подходе повышается гибкость и расширяемость функций по управлению устройством - вместо жесткого набора функций, сосредоточенных в единственном драйвере, администратор ОС может выбрать требуемый набор функций, установив нужный высокоуровневый драйвер. Если различным приложениям необходимо работать с различными логическими моделями одного и того же физического устройства, то для этого достаточно установить в системе несколько драйверов на одном уровне, работающих над одним аппаратным драйвером.
Количество уровней драйверов в подсистеме ввода-вывода обычно не ограничивается каким-либо пределом, но на практике чаще всего используют от двух до пяти уровней драйверов - слишком большое количество уровней может снизить скорость операций ввода-вывода. Несколько драйверов, управляющих одним устройством, но на разных уровнях, можно рассматривать как набор отдельных драйверов или как один многоуровневый драйвер.
Высокоуровневые драйверы оформляются по тем же правилам и придерживаются тех же внутренних интерфейсов, что и аппаратные драйверы. Единственным отличием является то, что высокоуровневые драйверы, как правило, не вызываются по прерываниям, так как взаимодействуют с управляемым устройством через посредничество аппаратных драйверов. Менеджер ввода-вывода управляет драйверами однотипно, независимо от того, к какому уровню он относится. При наличии большого количества драйверов разного уровня усложняются связи между ними, что, в свою очередь, усложняет их взаимодействие, и именно эта ситуация привела к стандартизации внутреннего интерфейса в подсистеме ввода-вывода и выделения специальной оболочки в виде менеджера ввода-вывода, выполняющего служебные функции по организации работы драйверов.
Рассмотрим, как общие принципы построения многоуровневых драйверов могут быть реализованы при управлении определенными типами внешних устройств.
В подсистеме управления дисками аппаратные драйверы поддерживают для верхних уровней представление диска как последовательного набора блоков одинакового размера, преобразуя вместе с контроллером номер блока в более сложный адрес, состоящий из номеров цилиндра, головки и сектора. Однако такие понятия, как «файл» и «файловая система», аппаратные драйверы дисков не поддерживают – эти удобные для пользователя и программиста логические абстракции создаются на более высоком уровне программным обеспечением файловых систем, которое в современных ОС также оформляется как драйвер, только высокоуровневый. Наличие универсальной среды, создаваемой менеджером ввода-вывода, позволяет достаточно просто решить проблему поддержки в ОС нескольких файловых систем одновременно. Для этого в ОС устанавливается несколько высокоуровневых драйверов (на рисунке это драйверы файловых систем 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 все устройства рассматриваются как некоторые виртуальные (специальные) файлы, что дает возможность использовать общий набор базовых операций ввода-вывода для любых устройств независимо от их специфики. Эти вопросы обсуждаются в следующем разделе, посвященном файлам и файловым системам.
Устройства делят на две категории (некоторые не попадают ни в одну):
блочные устройства - информация считывается и записывается по блокам, блоки имеют свой адрес (диски)
символьные устройства - информация считывается и записывается посимвольно (принтер, сетевые карты, мыши)
9.1.2 Контроллеры устройств
Устройства ввода-вывода обычно состоят из двух частей:
механическая (не надо понимать дословно) - диск, принтер, монитор
электронная - контроллер или адаптер
Если интерфейс между контроллером и устройством стандартизован (ANSI, IEEE или ISO), то независимые производители могут выпускать совместимые как контроллеры, так и устройства. Например: диски IDE или SCSI.
Операционная система обычно имеет дело не с устройством, а с контроллером. Контроллер, как правило, выполняет простые функции, например, при считывании с диска, преобразует поток бит в блоки, состоящие из байт, и осуществляют контроль и исправление ошибок, проверяется контрольная сумма блока, если она совпадает с указанной в заголовке сектора, то блок считан без ошибок, если нет, то считывается заново.
9.1.3 Отображаемый на адресное пространство памяти ввод-вывод
Каждый контроллер имеет несколько регистров, которые используются для взаимодействия с центральным процессором. При помощи этих регистров ОС управляет (считывает, пишет, включает и т.д.) и определяет состояние (готовность) устройства.
У многих устройств есть буфер данных (например: видеопамять).
Реализации доступа к управляющим регистрам и буферам:
отображаемый на адресное пространство памяти ввод-вывод - регистры отображаются на адресное пространство памяти.
Недостатки
- при кэшировании памяти, могут кэшироваться и регистры устройств
- все устройства должны проверять все обращения к памяти, чтобы определить, на какие им реагировать. На одной общей шине это реализуется легко, но на нескольких будут проблемы.
смешанная реализация - используется в х86 и Pentium,
от 0 до 64К отводится портам,
от 640 до 1М зарезервировано под буферы данных.
Способы реализации доступа к управляющим регистрам и буферам
9.1.4 Прямой доступ к памяти (DMA - Direct Memory Access)
Прямой доступ к памяти реализуется с помощью DMA - контроллера.
Контроллер содержит несколько регистров:
регистр адреса памяти
управляющие регистры, могут содержать:
- порт ввода-вывода
- чтение или запись
- единицы переноса (побайтно или пословно)
Без контроллера происходит следующее:
Процессор дает команду дисковому контроллеру прочитать данные в буфер,
Считываются данные в буфер, контроллер проверяет контрольную сумму считанных данных (проверка на ошибки). Процессор, до прерывания, переключается на другие задания.
Контроллер диска инициирует прерывание
Операционная система начинает работать и может считывать из буфера данные в память
Работа DMA - контроллера
С контроллером происходит следующее:
Процессор программирует контроллер (какие данные и куда переместить)
Процессор дает команду дисковому контроллеру прочитать данные в буфер
Считываются данные в буфер, контроллер диска проверяет контрольную сумму считанных данных, (процессор, до прерывания, переключается на другие задания).
Контроллер DMA посылает запрос на чтение дисковому контроллеру
Контроллер диска поставляет данные на шину, адрес памяти уже находится на шине, происходит запись данных в память
Когда запись закончена, контроллер диска посылает подтверждение DMA контроллеру
DMA контроллер увеличивает используемый адрес и уменьшает значение счетчика байтов
Все повторяется с пункта 4, пока значение счетчика не станет равной нулю.
Контроллер DMA инициирует прерывание
Операционной системе не нужно копировать данные в память, они уже там.
9.1.5 Прерывания
После того как устройство ввода-вывода начало работу, процессор переключается на другие задачи.
Чтобы сигнализировать процессору об окончании работы, устройство инициализирует прерывание, выставляя сигнал на выделенную устройству линию шины (а не выделенный провод).
Контроллер прерываний - обслуживает поступающие прерывания от устройств.
Если необработанных прерываний нет, прерывание выполняется немедленно.
Если необработанных прерываний есть, контроллер игнорирует прерывание. Но устройство продолжает удерживать сигнал прерывания на шине до тех пор, пока оно не будет обработано.
Устройство выставляет сигнал прерывания
Контроллер прерываний инициирует прерывание, указывая номер устройства
Процессор начинает выполнять обработку прерывания, вызывая процедуру
Эта процедура подтверждает получение прерывания контроллеру прерываний
9.2 Принципы программного обеспечения ввода-вывода
9.2.1 Задачи программного обеспечения ввода-вывода
Основные задачи, которые должно решать программное обеспечение ввода-вывода:
Независимость от устройств - например, программа, читающая данные из файла не должна задумываться с чего она читает (CD, HDD и др.). Все проблемы должна решать ОС.
Единообразное именование - имя файла или устройства не должны отличаться. (В системах UNIX выполняется дословно).
Обработка ошибок - ошибки могут быть отловлены на уровне контроллера, драйвера и т.д.
Перенос данных - синхронный и асинхронный (в последнем случае процессор запускает перенос данных, и переключается на другие задачи до прерывания).
Проблема выделенных (принтер) и невыделенных (диск) устройств - принтер должен предоставляться только одному пользователю, а диск многим. ОС должна решать все возникающие проблемы.
Три основных способа осуществления операций ввода-вывода:
Управляемый прерываниями ввод-вывод
Ввод-вывод с использованием DMA
Рассмотрим их подробнее.
9.2.2 Программный ввод-вывод
В этом случае всю работу выполняет центральный процессор.
Рассмотрим процесс печати строки ABCDEFGH этим способом.
Этапы печати строки ABCDEFGH
Строка для печати собирается в пространстве пользователя.
Обращаясь к системному вызову, процесс получает принтер.
Обращаясь к системному вызову, процесс просит распечатать строку на принтере.
Операционная система копирует строку в массив, расположенный в режиме ядра.
ОС копирует первый символ в регистр данных принтера, который отображен на памяти.
Символ печатается на бумаге.
Указатель устанавливается на следующий символ.
Процессор ждет, когда бит готовности принтера выставится в готовность.
При использовании буфера принтера, сначала вся строка копируется в буфер, после этого начинается печать.
9.2.3 Управляемый прерываниями ввод-вывод
Если в предыдущем примере буфер не используется, а принтер печатает 100 символов в секунду, то на каждый символ будет уходить 10мс, в это время процессор будет простаивать, ожидая готовности принтера.
Рассмотрим тот же пример, но с небольшим усовершенствованием.
До пункта 8 тоже самое.
Процессор не ждет готовности принтера, а вызывает планировщик и переключается на другую задачу. Печатающий процесс блокируется.
Когда принтер будет готов, он посылает прерывание процессору.
Процессор переключается на печатающий процесс.
9.2.4 Ввод-вывод с использованием DMA
Недостаток предыдущего метода в том, что прерывание происходит при печати каждого символа.
Алгоритм не отличается, но всю работу на себя берет контроллер DMA.
9.3 Программные уровни и функции ввода-вывода
Четыре уровня ввода-вывода:
9.3.1 Обработчики прерываний
Прерывания должны быть скрыты как можно глубже в недрах операционной системы, чтобы как можно меньшая часть ОС имела с ними дело. Лучше всего блокировать драйвер, начавший ввод-вывод.
Драйвер начинает операцию ввод-вывод.
Обработчик прерываний начинает работу
Обработчик прерываний может разблокировать драйвер (например, выполнив на семафоре процедуру up)
9.3.2 Драйвера устройств
Драйвер устройства - необходим для каждого устройства. Для разных ОС нужны разные драйверы.
Драйверы должны быть частью ядра (в монолитной системе), что бы получить доступ к регистрам контроллера.
Это одна из основных причин приводящих к краху операционных систем. Потому что драйверы, как правило, пишутся производителями устройств, и вставляются в ОС.
Логическое расположение драйверов устройств. На самом деле обмен данными между контроллерами и драйверами идет по шине.
Драйвера должны взаимодействовать с ОС через стандартные интерфейсы.
Стандартные интерфейсы, которые должны поддерживать драйвера:
Для блочных устройств
Для символьных устройств
Раньше для установки ядра приходилось перекомпилировать ядра системы.
Сейчас в основном ОС загружают драйверы. Некоторые драйверы могут быть загружены в горячем режиме.
Функции, которые выполняют драйвера:
обработка запросов чтения или записи
управление энергопотреблением устройства
прогрев устройства (сканера)
включение устройства или запуска двигателя
9.3.3 Независимое от устройств программное обеспечение ввода-вывода
Функции независимого от устройств программного обеспечения ввода-вывода:
Единообразный интерфейс для драйверов устройств,
Захват и освобождение выделенных устройств (блокирование)
Размер блока, не зависящий от устройств
Единообразный интерфейс для драйверов устройств
Кроме интерфейса, в него также входят проблемы,
Буферизация
Рассмотрим несколько примеров буферизации.
a) Не буферизованный ввод - после ввода каждого символа происходит прерывание
b) Буферизация в пространстве пользователя - приходится держать загруженными необходимые страницы памяти в физической памяти.
c) Буферизация в ядре с копированием в пространство пользователя - страница загружается только когда буфер ядра полный, данные из буфера ядра в буфер пользователя копируется за одну операцию. Проблема может возникнуть, когда буфер ядра полный, а страница буфера пользователя еще не загружена.
d) Двойная буферизация в ядре - если один буфер заполнен, и пока он выгружается, символы пишутся во второй буфер.
Наибольшее число ошибок возникает именно от операции ввода-вывода, поэтому их нужно определять как можно раньше. Ошибки могут быть очень разные в зависимости от устройств.
Захват и освобождение выделенных устройств
Для устройств (принтер) с которыми должен работать в одно время только один процесс, необходима возможность захвата и освобождения устройств. Когда один процесс занял устройство, остальные встают в очередь.
Независимый от устройств размер блока
Размер блока должен быть одинаковый для верхних уровней, и не зависеть от устройств (размеров секторов на диске).
9.3.4 Программное обеспечение ввода-вывода пространства пользователя
Функции этого обеспечения:
Обращение к системным вызовам ввода-вывода (через библиотечные процедуры).
Форматный ввод-вывод (меняют формат, например, в ASCII)
Спулинг (для выделенных устройств) - создается процесс (например, демон печати) и каталог спулера.
Как уважаемый хабрапользователь наверняка знает, «драйвер устройства» — это компьютерная программа управляющая строго определенным типом устройства, подключенным к или входящим в состав любого настольного или переносного компьютера.
Основная задача любого драйвера – это предоставление софтового интерфейса для управления устройством, с помощью которого операционная система и другие компьютерные программы получают доступ к функциям данного устройства, «не зная» как конкретно оно используется и работает.
Обычно драйвер общается с устройством через шину или коммуникационную подсистему, к которой подключено непосредственное устройство. Когда программа вызывает процедуру (очередность операций) драйвера – он направляет команды на само устройство. Как только устройство выполнило процедуру («рутину»), данные посылаются обратно в драйвер и уже оттуда в ОС.
Любой драйвер является зависимым от самого устройства и специфичен для каждой операционной системы. Обычно драйверы предоставляют схему прерывания для обработки асинхронных процедур в интерфейсе, зависимом от времени ее исполнения.
Любая операционная система обладает «картой устройств» (которую мы видим в диспетчере устройств), для каждого из которых необходим специфический драйвер. Исключения составляют лишь центральный процессор и оперативная память, которой управляет непосредственно ОС. Для всего остального нужен драйвер, который переводит команды операционной системы в последовательность прерываний – пресловутый «двоичный код».
Как работает драйвер и для чего он нужен?
Основное назначение драйвера – это упрощение процесса программирования работы с устройством.
Он служит «переводчиком» между хардовым (железным) интерфейсом и приложениями или операционными системами, которые их используют. Разработчики могут писать, с помощью драйверов, высокоуровневые приложения и программы не вдаваясь в подробности низкоуровневого функционала каждого из необходимых устройств в отдельности.
Как уже упоминалось, драйвер специфичен для каждого устройства. Он «понимает» все операции, которые устройство может выполнять, а также протокол, с помощью которого происходит взаимодействие между софтовой и железной частью. И, естественно, управляется операционной системой, в которой выполняет конкретной приложение либо отдельная функция самой ОС («печать с помощью принтера»).
Если вы хотите отформатировать жесткий диск, то, упрощенно, этот процесс выглядит следующим образом и имеет определенную последовательность: (1) сначала ОС отправляет команду в драйвер устройства используя команду, которую понимает и драйвер, и операционная система. (2) После этого драйвер конкретного устройства переводит команду в формат, который понимает уже только устройство. (3) Жесткий диск форматирует себя, возвращает результат драйверу, который уже впоследствии переводит эту команду на «язык» операционной системы и выдает результат её пользователю (4).
Как создается драйвер устройства
Для каждого устройства существует свой строгий порядок выполнения команд, называемой «инструкцией». Не зная инструкцию к устройству, невозможно написать для него драйвер, так как низкоуровневые машинные команды являются двоичным кодом (прерываниями) которые на выходе отправляют в драйвер результат, полученный в ходе выполнения этой самой инструкции.
При создании драйвера для Линукса, вам необходимо знать не только тип шины и ее адрес, но и схематику самого устройства, а также весь набор электрических прерываний, в ходе исполнения которых устройство отдает результат драйверу.
Написание любого драйвера начинается с его «скелета» — то есть самых основных команд вроде «включения/выключения» и заканчивая специфическими для данного устройства параметрами.
И чем драйвер не является
Часто драйвер устройства сравнивается с другими программами, выполняющими роль «посредника» между софтом и/или железом. Для того, чтобы расставить точки над «i», уточняем:
- Драйвер не является интерпретатором, так как не исполняется напрямую в софтовом слое приложения или операционной системы.
- Драйвер не является компилятором, так как не переводит команды из одного софтового слоя в другой, такой же.
Ну и на правах рекламы – вы всегда знаете, где скачать новейшие драйвера для любых устройств под ОС Windows.
Опять вернёмся в традиционную область разработки операционных систем (и приложений для микроконтроллеров) — написание драйверов.
Я попробую выделить некоторые общие правила и каноны в этой области. Как всегда — на примере Фантома.
Драйвер — функциональная компонента ОС, ответственная за отношения с определённым подмножеством аппаратуры компьютера.
С лёгкой руки того же Юникса драйвера делятся на блочные и байт-ориентированные. В былые времена классическими примерами были драйвер диска (операции — записать и прочитать сектор диска) и драйвер дисплея (прочитать и записать символ).
В современной реальности, конечно, всё сложнее. Драйвер — типичный инстанс-объект класса, и классов этих до фига и больше. В принципе, интерфейс драйверов пытаются как-то ужать в прокрустово ложе модели read/write, но это самообман. У драйвера сетевой карты есть метод «прочитать MAC-адрес карты» (который, конечно, можно реализовать через properties), а у драйвера USB — целая пачка USB-специфичных операций. Ещё веселее у графических драйверов — какой-нибудь bitblt( startx, starty, destx, desty, xsize, ysize, operation ) — обычное дело.
Цикл жизни драйвера, в целом, может быть описан так:
- Инициализация: драйвер получает ресурсы (но не доступ к своей аппаратуре)
- Поиск аппаратуры: драйвер получает от ядра или находит сам свои аппаратные ресурсы
- Активация — драйвер начинает работу
- Появление/пропадание устройств, если это уместно. См. тот же USB.
- Засыпание/просыпание аппаратуры, если это уместно. В контроллерах часто неиспользуемая аппаратура выключается для экономии.
- Деактивация драйвера — обслуживание запросов прекращается
- Выгрузка драйвера — освобождаются все ресурсы ядра, драйвер не существует.
(Вообще я написал в прошлом году черновик открытой спецификации интерфейса драйвера — см. репозиторий и документ.)
Мне известны три модели построения драйвера:
Драйвер на основе поллинга (циклического опроса) устройства
Такие драйвера применяются только с большого горя или по большой необходимости. Или если это простая встроенная микроконтроллерная система, в которой и есть-то всего два драйвера. Например, конвертор интерфейсов serial port TCP, в котором сеть работает по прерываниям, работу с последовательным портом может, в принципе, выполнять и поллингом. Если не жалко избытка тепла и затрат энергии.
Есть и ещё одна причина: такие драйвера практически неубиваемы. Поэтому, например, в ОС Фантом отладочная выдача ядра в последовательный порт сделана именно так.
В цикле проверяем готовность порта принять байт, передаём байт, закончили упражнение.
Такой драйвер, как нетрудно видеть, пожирает процессор в ожидании готовности устройства. Это можно починить, если скорость работы самого драйвера некритична:
Но, конечно, в целом это никуда не годная (кроме вышеприведённого случая:) модель.
Драйвер на основе прерываний
Общая структура такого драйвера выглядит вот как:
Фактически, такой драйвер порождает для себя псевдо-нить: поток управления, который живёт только на поступлении прерываний от устройства.
Как только драйвер получает очередной запрос на запись, он включает прерывания и «вручную» инициирует отправку в устройство первого байта данных. После чего входящая нить засыпает, ожидая конца передачи. А может и вернуться, если нужна асинхронная работа. Теперь драйвер будет ждать прерывания от устройства. Когда устройство «прожуёт» полученный байт, оно сгенерирует прерывание, при обслуживании которого драйвер или отправит очередной байт (и будет ждать очередного прерывания), или закончит работу, выключит прерывания и «отпустит» ждущую внутри dev_write() нить.
Что забыто
Прежде чем мы перейдём к последней модели драйвера, перечислим вещи, которые я (намеренно) пропустил в предыдущем повествовании.
Обработка ошибок
В нашем псевдокоде никак не проверяется успешность ввода-вывода. Реальное устройство может отказать или сообщить о неисправности носителя. Вынули кабель из порта локалки, на диске случился плохой блок. Драйвер должен обнаружить и обработать.
Таймауты
Устройство может сломаться и просто не ответить на запрос прерыванием, или никогда не выставить бит готовности. Драйвер должен запросить таймерное событие, которое бы вывело его из «ступора» на такой случай.
Смерть запроса
Если окружающая нас ОС это позволяет, то надо быть готовым к тому, что вошедшая в драйвер нить, в рамках которой «пришёл» запрос ввода-вывода, может быть просто убита. Это не должно приводить к фатальным последствиям для драйвера.
Синхронизация
Для простоты я указываю в качестве примитива синхронизации cond. В реальном драйвере это невозможно — cond требует объемлющего mutex в точке синхронизации, а в прерывании какой уж mutex — нельзя! Вот в последней модели, драйвере с собственной нитью, можно применять cond как средство синхронизации нити пользователя и нити драйвера. А вот синхронизация с прерыванием — только spinlock и семафор, причём реализация семафора должна быть готова к возможности активировать (открыть) семафор из прерывания. (В Фантоме это так и есть)
Драйвер на основе нити
От предыдущего он отличается тем, что имеет собственную нить, которая выполняет ввод-вывод.
Преимущество такого драйвера в том, что из нити можно позволить себе куда больше, чем из хендлера прерывания — можно выделять память, управлять таблицами страниц и вообще звать любую функцию ядра. Из прерывания нельзя позволить себе длинные и, тем более, блокирующие операции.
Отметим, что есть третья, промежуточная модель, в которой драйвер не имеет своей нити, а выполняет всё то же самое из нити запроса ввода-вывода. Но, во-первых, см. пункт о том, что её могут убить, во-вторых это жлобство :), а в третьих — не всегда она (нить) такого хочет. Иным бы хотелось асинхронного обслуживания.
Блочный ввод-вывод, сортировка и заборы
Дисковые драйвера обычно имеют на входе очередь запросов — ОС генерирует запросы на ввод-вывод пачками, и все запросы на уровне драйвера асинхронны. При этом хороший драйвер имеет собственную стратегию обслуживания запросов, причём — обслуживания не в порядке поступления.
Действительно, если на обычном дисковом устройстве выполнять запросы в том порядке, в котором они прилетели, головке накопителя придётся совершать хаотичные движения по диску, замедляя ввод-вывод.
Обычно драйвер просто сортирует очередь запросов по номеру блока и обслуживает их так, чтобы головка диска последовательно двигалась от внешней дорожки к внутренней, или наоборот. Это сильно помогает.
Но не всякую пару запросов можно поменять местами. Если файловая система (или её аналог) решила, что ей надо гарантировать целостность данных на диске, она бы очень хотела убедиться в том, что определённая группа запросов завершена. Для этого в очередь запросов вставляется специальный запрос ввода-вывода, который запрещает перемешивать запросы до себя с запросами после себя.
Кроме того, плохая идея переставлять местами запрос на запись блока N и запрос на чтение того же блока. Впрочем, это вопрос договорённостей.
Программа, которая общается с контроллером устройства ввода-вывода, отдает ему команды и получает ответы, называется драйвером устройства.
Каждый производитель контроллеров должен поставлять драйверы для поддерживаемых им операционных систем. Для того, чтобы получить возможность использовать драйвер, его нужно установить в операционную систему так, чтобы он мог работать в режиме ядра.
Теоретически драйверы могут работать вне ядра, но такую возможность поддерживают всего несколько существующих систем, так как для этого требуется, чтобы драйвер в пространстве пользователя имел доступ к устройству неким контролируемым способом - очень редко поддерживаемое свойство.
Три способа установки драйвера в ядро.
- Первый способзаключается в том, чтобы заново скомпоновать ядро вместе с новым драйвером и затем перезагрузить систему. Так работает множество систем UNIX.
- Второй способ: создать запись во входящем в операционную систему файле, говорящую о том, что требуется драйвер, и затем перезагрузить систему. Во время начальной загрузки операционная система сама находит нужные драйверы и загружает их. Так работает система Windows.
- Третий способ: операционная система может принимать новые драйверы, не прерывая работы, и оперативно устанавливать их, не нуждаясь при этом в перезагрузке. Этот способ редко используется, но сейчас он становится все более и более распространенным. Такие съемные устройства, как шины USB и IEEE 1394, всегда нуждаются в динамически загружаемых драйверах.
Ввод и вывод данных можно осуществлять тремя различными способами (рис 11.1)
Способ ввода-вывода | Без использования прерываний | С использованием прерываний |
Передача данных из устройства в/в в память с использованием процессора | Программируемый ввод/вывод (режим опроса готовности) | Ввод/вывод, управляемый прерыванием (режим обмена с прерыванием) |
Прямая передача данных из устройства ввода/вывода в память | Прямой доступ к памяти(DMA) |
Рис. 11.1. Способы ввода-вывода
- Управление в/в осуществляет ЦП– программный канал обмена данными между ОП и ВУ
- Управление в/в осуществляет специальное дополнительное оборудование –канал прямого доступа.
- Программируемый ввод-вывод (режим опроса готовности). Синхронное управление.Простейший метод состоит в том, что пользовательская программа выдает системный запрос, который ядро транслирует в вызов процедуры соответствующего драйвеpa. Затем драйвер начинает процесс ввода-вывода. В это время драйвер выполняет очень короткий программный цикл, постоянно опрашивая готовность устройства, с которым он работает (обычно есть некий бит, который указывает на то, что устройство все еще занято). По завершении операции ввода-вывода драйвер помещает данные туда, куда требуется, и возвращается в исходное состояние. Затем операционная система возвращает управление программе, осуществлявшей вызов. Этот метод называется ожиданием готовности или активным ожиданием и имеет один недостаток: процессор должен опрашивать устройство до тех пор, пока оно не завершит свою работу.
В набор используемых команд входят команды ввода-вывода, принадлежащие следующим категориям.
- Управление. Команды этой категории используются для того, чтобы привести внешнее устройство в действие и сообщить ему, что нужно делать. Например, блоку с магнитной лентой можно отдать команду перемотки или перемещения вперед на одну запись.
- Состояние. Используется для проверки состояния контроллера ввода-вывода и соответствующих периферийных устройств.
- Передача. Используется для чтения и/или записи данных в регистры процессора и внешние устройства и из регистров процессора и внешних устройств.
2. Режим обмена с прерываниями (асинхронное управление). При втором способе драйвер запускает устройство и просит его выдать прерывание по окончании ввода-вывода. После этого драйвер возвращает данные, операционная система блокирует программу вызова, если это нужно, и начинает выполнять другие задания. Когда контроллер обнаруживает окончание передачи данных, он генерирует прерывание, чтобы сигнализировать о завершении операции.
Процесс ввода-вывода в этом случае состоит из следующих шагов (рис. 11.2):
Рис. 11.2. Ввод-вывод, управляемый прерыванием
шаг 1. Драйвер передает команду контроллеру, записывая информацию в регистры устройства. Затем контроллер запускает устройство
шаг 2. Когда контроллер заканчивает чтение или запись того количества байтов, которое ему было указано передать, он посылает сигнал микросхеме контроллера прерываний, используя определенные провода шины.
шаг 3. Если контроллер прерываний готов к приему прерывания (а этого может и не быть, если он занят прерыванием более высокого приоритета), то он подает сигнал на определенный контакт процессора информируя центральный процессор.
шаг 4.Контроллер прерываний выставляет номер устройства на шину так, чтобы центральный процессор мог прочесть его и узнать, какое устройство только что завершило свою работу (ведь в одно и то же время могут работать несколько устройств).
Как только центральный процессор решил принять прерывание, содержимое счетчика команд (PC) и слова состояния процессора (PSW) помещается в текущий стек, а процессор переключается в режим работы ядра. Номер устройства может использоваться как индекс части памяти, служащий для поиска адреса обработчика прерываний данного устройства. Эта часть памяти называется вектором прерываний. Когда обработчик прерываний (это часть драйвера устройства, пославшего прерывание) начинает свою работу, он удаляет расположенные в стеке счетчик команд и слово состояния процессора, сохраняет их и запрашивает устройство, чтобы получить информацию о его состоянии. После того как обработка прерывания целиком завершена, управление возвращается кработавшей до этого программе пользователя, к той команде, выполнение которой еще не было закончено.
Для того чтобы не потерять связь с устройством может быть запущен отсчет времени, в течение которого устройство обязательно должно выполнить команду и выдать таки сигнал запроса на прерывание.
Максимальный интервал времени, в течение которого устройство ввода/вывода или его контроллер должны выдать сигнал запроса на прерывание, часто называют установкой тайм-аута.
Драйверы, работающие в режиме прерываний, представляют собой сложный комплекс программных модулей и могут иметь несколько секций:
Секция запускаинициирует операцию ввода/вывода. Эта секция запускается для включения устройства ввода/вывода либо просто для инициации очередной операции ввода/вывода.
Секция продолжения(их может быть несколько, если алгоритм управления обменом данными сложный и требуется несколько прерываний для выполнения одной логической операции) осуществляет основную работу по передаче данных.
Секция продолжения, собственно говоря, и является основным обработчиком прерывания.
Используемый интерфейс может потребовать для управления вводом/выводом несколько последовательностей управляющих команд, а сигнал прерывания у устройства, как правило, только один.
Поэтому после выполнения очередной секции прерывания супервизор прерываний при следующем сигнале готовности должен передать управление другой секции.
Это делается за счет изменения адреса обработки прерывания после выполнения очередной секции, если же имеется только одна секция прерываний, то она сама передает управление тому или иному модулю обработки.
Секция завершенияобычно выключает устройство ввода/вывода либо просто завершает операцию.
Управление операциями ввода/вывода в режиме прерываний требует больших усилий со стороны системных программистов — такие программы создавать сложнее, чем те, что работают в режиме опроса готовности.
Примером тому может служить ситуация с драйверами, обеспечивающими печать. Так, в ОС Windows (и Windows 9x, и Windows NT) драйвер печати через параллельный порт работает не в режиме с прерываниями, как это сделано в других ОС, а в режиме опроса готовности, что приводит к 100%-й загрузке центрального процессора на все время печати. При этом, естественно, выполняются и другие задачи, запущенные на исполнение, но исключительно за счет того, что ОС Windows реализует вытесняющую мультизадачность и время от времени прерывает процесс управления печатью и передает центральный процессор остальным задачам.
3. Прямой доступ к памяти. Третий метод ввода-вывода информации заключается в использовании специального контроллера прямого доступа к памяти (DMA, Direct Memory Access), который управляет потоком битов между оперативной памятью и некоторыми контроллерами без постоянного вмешательства центрального процессора. Процессор вызывает микросхему DMA, говорит ей, сколько байтов нужно передать, сообщает адреса устройства и памяти, а также направление передачи данных и позволяет дальше действовать ей самой. По завершении работы DMA инициирует прерывание, которое обрабатывается так же, как было описано выше.
Операционная система может воспользоваться прямым доступом к памяти только при наличии аппаратного DMA-контроллера, который есть у большинства систем. Как правило, DMA-контроллер, устанавливаемый на материнской плате, обслуживает запросы по передаче данных нескольких различных устройств ввода-вывода, часто на конкурентной основе.
Где бы он ни располагался физически, DMA-контроллер может получать доступ к системной шине независимо от центрального процессора (рис. 11.3). Он содержит несколько регистров, доступных центральному процессору для чтения и записи.
Рис. 11.3. Ввод-вывод с использованием прямого доступа
К ним относятся регистр адреса памяти, счетчик байтов и один или более управляющих регистров. Управляющие регистры задают:
Читайте также: