рудования BIOS или писать новые драйверы с нуля. Для разработчиков MINIX выбор был несложен, так как возможности BIOS во многом не соответствовали потребностям MINIX. Конечно, для того чтобы выполнить начальную зафузку системы с дискеты или жесткого диска, монитор зафузки пользуется функциями BIOS, так как здесь практически нет другой альтернативы. Но зафуженная система с собственными драйверами ввода/вывода способна на гораздо больше, чем BIOS.

Второй вопрос звучит так: как, без поддержки BIOS, обеспечить работу драйверов с различным оборудованием? Чтобы сделать вопрос более конкретным, рассмотрим контроллеры жестких дисков, которые на системах, поддерживаемых MINIX, могут быть четырех принципиально различных типов. Это оригинальный 8-битный контроллер XT, 16-битный контроллер АТ и два различных контроллера для компьютеров серий PS/2. Есть несколько возможных путей решения данной проблемы.

1. Для каждого типа дискового контроллера компилировать отдельную версию операционной системы.

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

3. Встроить в ядро несколько различных драйверов и предоставить пользователю право выбрать подходяший.

Как мы увидим, эти решения не являются взаимоисключаюшими.

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

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

В третьем подходе, присущем MINIX, компилируются несколько драйверов, один из которых выбирается по умолчанию. Монитор начальной загрузки считывает различные параметры загрузки. Эти параметры могут быть введены

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

hd - xt

то используется драйвер диска для XT. Если подобного параметра не обнаружено, применяется драйвер по умолчанию.

В MINIX есть еще два средства, уменьщающие проблемы с различными драйверами жестких дисков. Прежде всего, это специальный драйвер, который в своей работе использует функции BIOS. Этот драйвер гарантированно заработает практически с любой системой. Чтобы выбрать его, необходимо задать следующий параметр загрузки:

hd = bios

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

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

Отступая в сторону, заметим, что этот урок тяжело нам дался. Ранние версии MINIX пытались инициализировать жесткий диск при загрузке системы. Если жесткого диска не было, система зависала. Такое поведение было особенно неприятным потому, что MINIX рассчитана и на машины без жесткого диска, хотя это и уменьшает доступный объем памяти и производительность.

В этом и следующем разделах мы будем рассматривать драйвер жесткого диска в стиле AT, устанавливаемый в MINIX по умолчанию. Это многоцелевой драйвер, обеспечивающий поддержку широкого диапазона контроллеров, как ранних, применявшихся в 286-х системах, так и современных EIDE-контроллеров. В основном общие аспекты работы жесткого диска, которые мы включим в рассмотрение, относятся и к остальным драйверам.

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

Некоторые контроллеры жестких дисков также поддерживают приводы CD-ROM со сменным носителем. В этом случае при обработке DEV OPEN должно прове-ряты;я наличие носителя в приводе. Для CD-ROM имеет значение и операция DEV CLOSE: она приводит к отпиранию дверцы привода и выбросу диска. В случае сменного носителя есть и другие сложности, в большей степени имеюшие отношение к гибким дискам, поэтому мы рассмотрим их позже. В данном случае, чтобы выбросить диск, используется операция DEV IOCTL, устанавливаюшая значение флага, который будет анализироваться при работе DEV CLOSE. Кроме того, DEV IOCTL применяется для записи и чтения таблиц разделов.

Каждый из запросов DEV READ, DEV WRITE и SCATTERED IO, как мы видели, выполняется в три действия: подготовка, планирование и завершение. В отличие от RAM-дисков у жесткого диска фазы планирования и завершения принципиально различны. Драйвер не задействует такие алгоритмы планирования перемеше-ния головки, как SSF или элеваторный алгоритм, но поддерживает более ограниченный алгоритм, объединяюший запросы последовательных секторов. При нормальной работе запросы обычно отправляются файловой системой, которую интересуют блоки, кратные 1024 байт. Драйвер же обрабатывает запросы, кратные величине сектора (512 байт). Пока поступаюшие запросы адресуют цепочку последовательных секторов, каждый новый запрос помешается в конец очереди. Эта очередь организована в виде массива, и, когда массив заполняется или поступает запрос, не укладывающийся в цепочку, делается вызов для завершения обмена данными.

Обыкновенные вызовы DEV READ и DEV WRnE могут запрашивать более одного блока, но за каждым вызовом процедуры планирования непосредственно следует вызов процедуры, которая обеспечивает, что текущий список запросов завершен. В случае операции SCATTEREDJO вызову завершающей процедуры может предшествовать несколько вызовов процедуры планирования. Пока запрашиваются блоки последовательных данных, список расширяется до заполнения массива. Вспомните, что у вызова SCATTEREDJO есть флаг, который отмечает необязательные запросы. Драйвер жесткого диска, как и драйвер RAM-диска, игнорирует этот флаг и доставляет все запрошенные блоки.

Рудиментарное планирование, которое драйвер жесткого диска осуществляет, откладывая выполнение на время запроса последовательных блоков, нужно рассматривать как второй шаг предполржительно трехэтапного алгоритма планирования. Сама файловая система при помощи рассеянного ввода/вывода могла бы реализовать что-либо наподобие(Элеватора в версии Теори, наподобие тому, как в запросе разрозненного ввода/вывода запросы сначала сортируются по номеру блока. Третий этап планирования происходит в контроллере современного диска, например, того, что описан в табл. 3.5. Подобные контроллеры достаточно умные и умеют хранить в буфере большой объем данных, тем самым обеспечивая максимальную эффективность передачи больших объемов данных при помощи внутренних алгоритмов, безотносительно к порядку поступления запросов.

См. [82]. - Примеч. ред.