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

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

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

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

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

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

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

 

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

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

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

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

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

Высокоуровневые драйверы оформляются по тем же правилам и придерживаются тех же внутренних интерфейсов, что и аппаратные драйверы. Как правило, высокоуров­невые драйверы не вызываются по прерываниям, так как взаимодействуют с устройст­вом через посредничество аппаратных драйверов.

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

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

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

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

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

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

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

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

Для разработки драйверов производителями внешних устройств необходимо нали­чие четкого, удобного, открытого и хорошо документированного интерфейса между драйверами и другими компонентами ОС. Драйвер взаимодействует, с одной стороны, с модулями ядра ОС (модулями подсистемы ввода-вывода, модулями системных вызо­вов, модулями подсистем управления процессами и памятью), а с другой стороны -с контроллерами внешних устройств. Поэтому существует два вида интерфейсов: интерфейс «драйвер-ядро» (Driver Kernel Interface, DKI) и интерфейс «драйвер-устройство» (Driver Device Interface).

Интерфейс «драйвер-ядро» должен быть стандартизован в любом случае. Подсис­тема ввода-вывода может поддерживать несколько различных интерфейсов DKI/DDI, предоставляя специфический интерфейс для устройств определенного класса. К наибо­лее общим классам относятся блочные устройства, например диски и символьные устройства, такие как клавиатура и принтеры. Может существовать класс сетевых адапте­ров и др. В большинстве современных ОС определен стандартный интерфейс, который должен поддерживать все блочные драйверы, и второй стандартный интерфейс, поддер­живаемый всеми символьными адаптерами. Эти интерфейсы включают наборы проце­дур, которые могут вызываться остальной операционной системой для обращения к драйверу. К этим процедурам относятся, например, процедуры чтения блока или записи символьной строки.

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

У драйверов устройств есть множество функций, перечисленных ниже :

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

· Проверка входных параметров запросов и обработка ошибок.

· Инициализация устройства и проверка статуса устройства.

· Управление энергопотреблением устройства.

· Регистрация событий в устройстве.

· Выдача команд устройству и ожидание их выполнения возможно в блокированном состоянии до поступления прерывания от устройства.

· Проверка правильности завершения операции.

· Передача запрошенных данных и статуса завершенной операции.

· Обработка нового запроса при незавершенном предыдущем запросе (для реентера­бельных драйверов).

 

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

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

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

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

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

Для поддержки процесса разработки драйверов операционной системы выпускает­ся так называемый пакет DDK (Driver Development Kit), представляющий собой набор инструментальных средств-библиотек, компиляторов и отладчиков.

Динамическая загрузка и выгрузка драйверов

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

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

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