А. Робачевский - Операционная система UNIX (1114671), страница 65
Текст из файла (страница 65)
Существует два основных метода встраивания кода иданных драйвера в ядро операционной системы: перекомпиляция ядра,позволяющая статически поместить драйвер, и динамическая загрузкадрайвера в ядро в процессе работы системы.www.books-shop.comустройств339Традиционно для встраивания драйвера в ядро UNIX требуется переком!пиляция ядра и перезапуск системы. Принципиально эта процедура неотличается от компиляции обычной программы, все компоненты ядра яв!ляются объектными модулями и редактор связей объединяет их с объект!ным модулем драйвера для получения исполняемого файла.
В этом случаедрайвер встраивается в ядро статически, т. е. независимо от фактическогоналичия устройства и ряда других причин, код и данные драйвера будутприсутствовать в ядре UNIX до следующей перекомпиляции.Однако тенденция развития современных версий операционной системыUNIX заключается в предоставлении возможности динамического расши!рения функциональности ядра.
Это, в частности, относится к файловойсистеме, драйверам устройств и сетевым протоколам (точнее, драйверамподсистемы STREAMS). Возможность работы с новыми периферийнымиустройствами без необходимости перекомпиляции ядра обеспечиваетсязагружаемыми драйверами. Вместо того чтобы встраивать модуль драйвера,основываясь на статических таблицах и интерфейсах, ядро содержит наборфункций, позволяющих загрузить необходимые драйверы и, соответствен!но, выгрузить их, когда необходимость работы с данным устройством от!падает. При этом структуры данных для доступа к драйверам устройствтакже являются динамическими.Динамическая установка драйвера в ядро операционной системы требуетвыполнения следующих операций:Размещение и динамическое связывание символов драйвера.
Этаоперация аналогична загрузке динамических библиотек, и выполня!ется специальным загрузчиком.Инициализация драйвера и устройства.Добавление точек входа драйвера в соответствующий коммутаторустройств.П Установка обработчика прерываний драйвера.Естественно, код динамически загружаемых драйверов сложнее, и содер!жит, помимо стандартных точек входа, ряд функций, отвечающих за за!грузку и выгрузку драйвера, а также ряд дополнительных структур.
При!мер дополнительных функций и структур данных, которые должны бытьопределены в динамически загружаемом драйвере операционной системыSolaris 2.5, приведен в табл. 5.2.Таблица 5.2. Дополнительные функции и структуры данных для загружаемых драйверовФункция инициализации и установки, вызываемая при за%грузке драйвераФункция, вызываемая перед выгрузкой драйвера, удаляю%щая его из системыȾɚɧɧɚɹɜɟɪɫɢɹɤɧɢɝɢɜɵɩɭɳɟɧɚɷɥɟɤɬɪɨɧɧɵɦɢɡɞɚɬɟɥɶɫɬɜɨɦ%RRNVVKRSɊɚɫɩɪɨɫɬɪɚɧɟɧɢɟɩɪɨɞɚɠɚɩɟɪɟɡɚɩɢɫɶɞɚɧɧɨɣɤɧɢɝɢɢɥɢɟɟɱɚɫɬɟɣɁȺɉɊȿɓȿɇɕɈɜɫɟɯɧɚɪɭɲɟɧɢɹɯɩɪɨɫɶɛɚɫɨɨɛɳɚɬɶɩɨɚɞɪɟɫɭpiracy@books-shop.com340Глава 5.Таблица 5.2 (продолжение)_inf оФункция, возвращающая информацию о драйвере по за%просу ядраstructСтруктура, используемая функциямии_inf опри загрузке, выгрузке и получении информации одрайвереstructСтруктура, экспортируемая ядру при загрузке драйвера, вчастности, содержит адреса точек входа в драйверПомимо этого Solaris 2.5 предоставляет ряд функций ядра для работы с дина!мически загружаемыми драйверами:mod_remove ( 9 F ) иmod.Блочные устройстваДрайверы блочных устройств предназначены для обслуживания перифе!рийного оборудования, обеспечивающего обмен данными с помощьюфрагментов фиксированной длины, называемыми блоками, размер которыхзначительно превышает один байт.
В основном эти драйверы используют!ся файловой подсистемой и подсистемой управления памятью. Например,свопинг характеризуется обменом данными с устройством вторичной па!мяти, размер которых обычно равен размеру страницы, что составляет4 или 8 Кбайт. Файловая подсистема производит чтение и запись данныхфрагментами, размер которых равен одному или нескольким блокам уст!ройства. Типичными представителями блочных устройств являются жест!кий и гибкий диски.Блочные устройства можно разделить на два типа в зависимости от того,используются ли они для хранения файловой системы или нет.
Соответст!венно различается и схема доступа к этим устройствам. В последнем слу!чае доступ к устройству осуществляется только через специальный файлустройства, представляющий интерфейс низкого уровня. Хотя обращениек устройствам, содержащим файловые системы, может также осуществ!ляться через интерфейс низкого уровня, доступ к таким устройствам, какправило, осуществляется процессом косвенно, через запросы к файловойсистеме. Например, чтение или запись обычного файла вызывает опера!ции с драйвером блочного устройства (жесткого диска), на котором распо!ложена файловая система, хранящая данный файл.
В этом случае обменданными происходит при активном участии буферного кэша, позволяю!щего минимизировать число обращений непосредственно к физическомуустройству.www.books-shop.comБлочные341Вообще говоря, операции ввода/вывода для блочного устройства могутбыть вызваны рядом событий:Чтением или записью в обычный файл.ОЧтением или записью непосредственно в специальный файл устройства.Операциями подсистемы управления памятью: страничным замеще!нием или свопингом.Доступ к блочным устройствам осуществляется с помощью трех основныхточек входа:иПри этом за факти!ческое выполнение ввода/вывода отвечает xxstrategy ( ) .
Единственнымаргументом, передаваемым этой функции, является указатель на структуруb u f , представляющую собой заголовок буфера обмена, с которой мы ужевстречались в предыдущей главе при разговоре о буферном кэше. Структу!ра buf содержит всю необходимую для операций ввода/вывода информа!цию. Основные поля структуры buf:Флаги. Определяют состояние буфера (например,или B_DONE) и направление передачи данныхB_PHYS).Указатели двухсвязного рабочего списка буферов, ожидаю%щих обработки драйверомРазмер буфераВиртуальный адрес буфераНомер блока начала данных на устройствеЧисло байтов, которые требуется передатьСтарший и младший номера устройстваИспользование заголовка buf при передачи блока данных показано нарис.
5.7.Ядро адресует дисковый блок, указывая vnode и смещение. Если доступосуществляется к специальному файлу устройства, то смещение являетсяфизическим, отсчитываемым от начала устройства. Например, если специ!альный файл устройстваобеспечивает доступ ко второмуразделу жесткого диска, то смещение будет отсчитываться от начала этогораздела.
Если vnode представляет обычный файл, то смещение являетсялогическим, отсчитываемым от начала файла.Таким образом, блок устройства, содержащего файловую систему, можетбыть адресован двумя способами — либо через обычный файл и логиче!ское смещение, либо через специальный файл устройства и физическоесмещение на этом устройстве. Это, в свою очередь, может привести к раз!личной идентификации одного и того же блока и, как следствие, двумразличным копиям блока в памяти.
Результатом такого несоответствияможет стать потеря или нарушение целостности данных. Поэтому непо!средственный доступ к специальному файлу такого устройства возможентолько при размонтированной файловой системе.www.books-shop.com342Глава 5.Рис. 5.7. Обмен данными с блочным устройством (диском)Поскольку каждый дисковый блок связан с каким!либо файлом и соответ!ственно с его vnode, а его образ в памяти — с физическими страницами,которые также связаны с vnode (через структуры описания физическойпамяти — page в SVR4, pfdat в SVR3), все операции ввода/вывода связа!ны с подкачкой и сохранением страниц и идентифицируются vnode.Символьные устройстваСимвольные устройства представляют собой значительную часть перифе!рийного оборудования системы, включая терминалы, манипуляторы(например, мышь), клавиатуру и локальные принтеры.
Основное отличиеэтих устройств от блочных заключается в том, что они, как правило, пере!дают небольшие объемы данных.Обмен данными с символьными устройствами происходит непосредствен!но через драйвер, минуя буферный кэш. При этом данные обычно копи!www.books-shop.comСимвольные343в драйвер из адресного пространства процесса, запросившего опе!рацию ввода/вывода.Если процесс сделал системный вызов ввода/вывода, например,илисо специальным файлом символьного устройства, запрос на!правляется в файловую подсистему. Поскольку доступ к устройству обслу!живается файловой системой specfs, рассмотренной ранее, в ответ на вы!полнение системного вызова процесса ядро выполняет вызов функцииилисоответственно дляилиДействия функцийипохожи.
Обе проверяюттип vnode и определяют, что устройство является символьным. Послеэтого с помощью коммутатора ядро выбирает соответствующую точку вхо!да драйвера, используя старший номер, хранящийся в поле v_rdev vnode,и вызывает эту функцию (соответственноилипе!редавая ей в качестве параметров старший и младший номера, ряд допол!нительных параметров, зависящих от конкретного вызова, а также явноили неявно адресует область копирования данных в адресном пространст!веИнтерфейс доступа низкого уровняСимвольные драйверы обеспечивают доступ не только к символьным уст!ройствам, например, к адаптеру последовательного или параллельногопортов, манипулятору "мышь", монитору или терминалам.
Часть символь!ных драйверов служит в качестве интерфейса доступа низкого уровня кблочным устройствам, таким как диски или накопители на магнитныхлентах.Большинство таких драйверов отличаются от соответствующих им драйве!ров блочных устройств характером выполнения операций ввода/вывода. Вто время как драйверы блочных устройств производят обмен д а н н ы м и сбуферным кэшем, драйверы доступа низкого уровня обеспечивают обменданных непосредственно с адресным пространством процесса. Отсутствиепосредника в виде буферного кэша устраняет необходимость в соверше!нии дополнительных операций копирования (драйвер — буферный кэш —буфер процесса), но в то же время лишает процесс услуг кэшированияданных, предоставляемых операционной системой.Интерфейс доступа низкого уровня используется многими системнымиутилитами обслуживания файловой системы, например,а такжерядом приложений, работающих с накопителями на магнитной ленте, на!примерилиЭтот интерфейс используется некоторымиНесколько иная схема применяется для драйверов подсистемы STREAMS, которые такжеимеютинтерфейс доступа.
Эти драйверы будутв даннойглаве в"Подсистема STREAMS".www.books-shop.com344Глава 5.ложениями, например СУБД, которые самостоятельно обеспечивают оп!тимизированные механизмы кэширования данных на уровне задачи.Поскольку драйверы низкого уровня не используют буферный кэш, онисамостоятельно обеспечивают необходимые буферы для совершения опе!рации ввода/вывода. На рис.
5.8 показаны отличия в характере выполненияоперации ввода/вывода с блочными устройствами в случаях, когда запросформируется при участии буферного кэша (драйверы блочных устройств),и когда манипуляция буфером производится драйвером самостоятельно(драйверы низкого уровня).ИнтерфейссистемныхвызововРис. 5.8. Различ%ные типы доступак блочным устрой%ствамБуферизацияОчевидно, что побайтная передача данных между драйвером символьногоустройства и прикладным процессом весьма неэффективна. При такомрежиме работы байт должен быть сначала скопирован в адресное про!www.books-shop.com345Символьныестранство драйвера, затем некоторое время должно пройти, прежде чемдрайвер сможет передать этот символ физическому устройству. Если приэтом устройство оказывается занятым, процесс должен ожидать заверше!ния предыдущей операции, что, скорее всего, вынудит его перейти в со!стояние сна и приведет к переключению контекста.Существует несколько способов преодолеть данную ситуацию, но все онипредполагают обеспечение некоторой буферизации данных драйвером уст!ройства.
Первый способ заключается в использовании прерываний, когдапри поступлении на устройство следующего символа, генерируется аппарат!ное прерывание, которое обрабатывается функцией xxintrдрайвера не!зависимо от функции xxwriteФункция обработки прерывания записы!вает данные в буфер, которые затем считываются функцией xxwriteЕсли устройство не поддерживает прерываний, их поступление можносэмулировать с помощью функции xxpollдрайвера устройства, котораявызывается ядром через определенные промежутки времени (обычно каж!дый сигнал таймера).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
