<<
>>

Драйверы устройств в MINIX 3

Для каждого из классов устройств ввода-вывода в MINIX существует отдельный драйвер. Эти драйверы являются полноценными процессами, каждый со своим состоянием, регистрами, стеком и т.
д. Драйверы взаимодействуют с файловой системой при помощи механизма передачи сообщений, как и любые другие процессы MINIX 3. Код простого драйвера можно уместить в одном файле. Драйверы виртуального диска, жесткого диска и дисковода для дискет расположены каждый в своем файле; кроме того, они используют общие функции работы с блочными устройствами, вынесенными в файлы driver.с и drvlib.c. Подобное разделение программного обеспечения на части, зависимые и независимые от аппаратного обеспечения, позволяет с легкостью приспосабливать его к самым разным конфигурациям оборудования. Хотя дисковые драйверы пользуются некоторыми фрагментами общего кода, каждый из них работает как отдельный процесс. Это изолирует драйверы друг от друга и ускоряет передачу данных.

Подобным же образом организован и исходный код драйвера терминала, где аппаратно-независимый код помещен в файле tty.

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

Кроме того, для групп сходных устройств, например для дисков и терминалов, есть еще и заголовочные файлы. Файл driver.h поддерживает все драйверы блочных устройств, а файл tty.h предоставляет общие определения для всех типов терминалов.

Поскольку система MINIX 3 построена на исполнении компонентов операционной системы в пользовательском пространстве как полностью независимых процессов, для нее характерны высокая степень модульности и приемлемая эффективность.

Это — одно из кардинальных отличий MINIX 3 от UNIX. В MINIX процесс, для того чтобы прочитать файл, посылает сообщение файловой системе. В свою очередь, файловая система может послать сообщение драйверу диска, запрашивая чтение необходимого блока. Драйвер диска использует вызовы ядра для фактического ввода- вывода и копирования данных между процессами. Эта последовательность (несколько упрощенная по сравнению с реальностью) изображена на рис. 3.12, а. За счет того, что взаимодействие происходит через механизм сообщений, обеспечивается стандартный коммуникационный интерфейс между частями системы.

В и№Х у каждого процесса есть две части: одна в пользовательском пространстве и другая в пространстве ядра (рис. 3.12, б). Когда процесс делает системный вызов, операционная система некоторым волшебным образом переключается из пользовательской области в область ядра. Такой механизм является пережитком МиЬТЮБ, где переключение было простым вызовом процедуры, а не ловушкой с сохранением состояния пользовательской части процесса, как в и№Х.

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

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

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

Для большинства операционных систем плата за переход к исполнению компонентов в пользовательском пространстве составила бы 5-10 %. Тем не менее многие системные разработчики не разделяют это убеждение.

В этой главе обсуждаются драйверы виртуального диска, жесткого диска, таймера и терминала. Стандартная комплектация MINIX 3 включает в себя также драйверы для дисковода гибких дисков и принтера, которые мы подробно не рассматриваем. Кроме того, имеются драйверы для последовательного интерфейса RS- 232, приводов CD-ROM, адаптера Ethernet и звуковой карты. Они могут быть скомпилированы отдельно и задействованы «на лету» в любой момент времени.

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

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

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

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

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

Таблица 3.3. Поля запросов от файловой системы к драйверам блочных устройств и ответов, отправляемых файловой системе

Структура основной части кода у каждого драйвера одинакова и в общих чертах приведена в листинге 3.1. При запуске системы управление передается каждому из драйверов с целью дать им возможность инициализировать внутренние таблицы и тому подобные данные. Завершив инициализацию, каждый из драйверов делает вызов receive, чтобы получить сообщение, и переходит в состояние блокировки. Когда сообщение приходит, запоминается, какой процесс его отправил, после чего вызывается подпрограмма для выполнения необходимых действий. После того как обработка запроса завершена, вызвавшему процессу отправляется сообщение с результатами, а драйвер переходит к началу цикла и ожидает новых сообщений.

Листинг 3.1. Общая структура основной процедуры драйвера ввода-вывода

/* Буфер сообщений */

void io_driver() {

initialize(); /* Вызывается только один раз при инициализации

while (TRUE) {

receive(ANY, &mess); /* Ожидаем запрос */

caller = mess.source; /* Процесс, сделавший запрос */

switch(mess.type) {

case READ: rcode = dev_read(&mess); break;

case WRITE: rcode = dev_write(&mess); break;

/* Тут находится код для выполнения других операций, таких как OPEN, CLOSE и IOCTL */ default: rcode = ERROR;

}

mess.type = DRIVER_REPLY;

mess.status = rcode; /* Код возврата */

send(caller, &mess); /* Отправляем ответ */

}

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

3.4.3.

<< | >>
Источник: Э. ТАНЕНБАУМ, А. ВУДХАЛЛ. ОПЕРАЦИОННЫЕ СИСТЕМЫ Разработка и реализация 3-е издание. 2007

Еще по теме Драйверы устройств в MINIX 3:

  1. Драйвер Счастья в Работе:
  2. Статья 265-1. Незаконное изготовление ядерного взрывного устройства или устройства, которое рассеивает радиоактивный материал или излучает радиацию
  3. Раздел V. Федеративное устройство
  4. § 6. Государственное устройство
  5. § 2. Форма государственного (территориально-политического) устройства
  6. § 5. Политико-территориальное устройство. Организация власти на местах
  7. Устройство мира
  8. 1.3.4. Устройство помещения
  9. § 1. Понятие и формы государственного устройства
  10. 7.4. Криминалистическое исследование взрывных устройств и взрывчатых веществ, а также следов их применения
  11. § 6. Политико-территориальное устройство. Областная автономия и местное самоуправление
  12. Глава 9. Федеративное устройство России
  13. § 6. Основы политико-территориального устройства
  14. М.Руссинович, Д.Соломон. Внутреннее устройство Microsoft Windows (главы 1–4), 2005
  15. Устройство дульного мира
  16. Устройство дульного мира
  17. § 6. Устройство детей, оставшихся без попечения родителей