Встраивание драйверов в ядро

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

Традиционно для встраивания драйвера в ядро UNIX требуется перекомпиляции

ядра и перезапуск системы. Принципиально эта процедура не

отличается от компиляции обычной программы, все компоненты ядра яв-

ляются модулями и редактор связей объединяет их с объект-

тным модулемдрайвера для получения исполняемого файла. В этом случае

драйвер встраивается в ядро статически, т. е. независимо от фактического

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

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

Динамическая установка драйвера в ядро операционной системы требует

выполнения следующих операций:

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

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

• Добавление точек входа драйвера в соответствующий коммутатор устройств.

• Установка обработчика прерываний драйвера.

Естественно, код динамически загружаемых драйверов сложнее, и содержит

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

дополнительных функций и структур данных, которые должны быть

определены в динамически загружаемом драйвере операционной системы

SOLARIS 2.5, приведен в табл. 5.2.

Помимо этого Solaris 2.5 предоставляет ряд функций ядра для работы с динамически загружаемыми драйверами: mod_install (9FJ, mod remove и mod_info(9F).

Блочные устройства

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

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

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

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

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

• Чтением или записью в обычный файл.

• чтением или записью непосредственно в специальный файл устройства.

• Операциями подсистемы управления памятью: страничным замеще­нием или свопингом.

Доступ к блочным устройствам осуществляется с помощью трех основных

Точек входа: ххореп (), xxclose () и xxstrategy (). При этом за фактически выполнение ввода/вывода отвечает xxstrategy (). Единственным аргументом, передаваемым этой функции, является указатель на структуру buf представляющую собой заголовок буфера обмена.

Структура buf содержит всю необходимую для операций ввода/вывода информацию.

Основные поля структуры buf:

b_flags Флаги. Определяют состояние буфера (например, b_busy или b__done) и направление передачи данных (b_read, B_WRITE, B_PHYS)

Av_back, av forw Указатели двухсвязного рабочего списка буферов, ожидающих обработки драйвером

b_bufsize Размер буфера

b_un. b_addr Виртуальный адрес буфера

b_blkno Номер блока начала данных на устройстве

b_bcount Число байтов, которые требуется передать

b_dev Старший и младший номера устройства

Использование заголовка buf при передачи блока данных показано на рис. 5.7.

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

логическим, отсчитываемым от начала файла.

Таким бразом, блок устройства, содержащего файловую систему, может

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

смещение на этом устройстве. Это, в свою очередь, может привести к различной

идентификации одного и того же блока и, как следствие, двум

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

может стать потеря или нарушение целостности данных. Поэтому непосредственный

доступ к специальному файлу такого устройства возможен

только при размонтированной файловой системе.

Поскольку каждый дисковый блок связан с каким-либо файлом и cooтветственно с его vnode, а его образ в памяти — с физическими страницами, которые также связаны с vnode (через структуры описания физической памяти — page в SVR4, pfdat в SVR3), все операции ввода/вывода связанны с подкачкой и сохранением страниц и идентифицируются vnode.