ЛЕКЦИЯ №14 Поддержка широкого спектра драйверов и простота включения нового драйвера в систему

Достоинством подсистемы ввода-вывода любой универсальной ОС является на­личие разнообразного набора драйверов для наиболее популярных периферийных устройств. Прекрасно спланированная и реализованная операционная сис­тема может потерпеть неудачу на рынке только из-за того, что в ее состав не включен достаточный набор драйверов и администраторы и пользователи выну­ждены искать нужный им драйвер для имеющегося у них внешнего устройства у производителей оборудования или, что еще хуже, заниматься его разработкой. Именно в такой ситуации оказались пользователи первых версий OS/2, и, возможно, это обстоятельство послужило в свое время не последней причиной сда­чи позиций этой неплохой операционной системы, богатой на драйверы ОС Win­dows 3.х.

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

Драйвер взаимодействует, с одной стороны, с модулями ядра ОС (модулями подсистемы ввода-вывода, модулями системных вызовов, модулями подсистем управления процессами и памятью и т. д.), а с другой стороны – с контроллера­ми внешних устройств. Поэтому существуют два типа интерфейсов: интерфейс “драйвер-ядро” (Driver Kernel Interface, DKI) и интерфейс “драйвер-устройство” (Driver Device Interface, DDI). Интерфейс “драйвер-ядро” должен быть стандар­тизован в любом случае, а интерфейс “драйвер-устройство” имеет смысл стан­дартизировать тогда, когда подсистема ввода-вывода не разрешает драйверу не­посредственно взаимодействовать с аппаратурой контроллера, а выполняет эти операции самостоятельно. Экранирование драйвера от аппаратуры является весьма полезной функцией, так как драйвер в этом случае становится независимым от аппаратной платформы. Подсистема ввода-вывода может поддерживать несколь­ко различных типов интерфейсов DKI/DDI, предоставляя специфический ин­терфейс для устройств определенного класса. Так, в ОС Windows NT для драй­веров сетевых адаптеров существует интерфейс стандарта NDIS (Network Driver Interface Specification), в то время как драйверы сетевых транспортных протоко­лов взаимодействуют с верхними слоями сетевого программного обеспечения по интерфейсу TDI (Transport Driver Interface).

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

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

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

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

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

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

Поддержка нескольких файловых систем

Диски представляют особый род периферийных устройств, так как именно на них хранится большая часть как пользовательских, так и системных данных. Дан­ные на дисках организуются в файловые системы, и свойства файловой системы во многом определяют свойства самой ОС – ее отказоустойчивость, быстродей­ствие, максимальный объем хранимых данных. Популярность файловой систе­мы часто приводит к ее миграции из “родной” ОС в другие операционные систе­мы – например, файловая система FAT появилась первоначально в MS-DOS, но затем была реализована в OS/2, семействе MS Windows и многих реализациях UNIX. Ввиду этого поддержка нескольких популярных файловых систем для под­системы ввода-вывода также важна, как и поддержка широкого спектра периферийных устройств. Важно также, чтобы архитектура подсистемы ввода-вывода позволяла достаточно просто включать в ее состав новые типы файловых сис­тем, без необходимости переписывания кода. Обычно в операционной системе имеется специальный слой программного обеспечения, отвечающий за решение данной задачи, например слой VFS (Virtual File System) в версиях UNIX на осно­ве кода System V Release 4.

Поддержка синхронных и асинхронных

операций ввода-вывода

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

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