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

При записи загрузочного сектора на диск в него вписываются номера секторов, необходимые ему, чтобы найти программу boot. Причина в том, что до загрузки операционной системы невозможно найти местоположение нужного файла по его имени. За формирование загрузочного сектора и вписывание в него правильных номеров секторов ответственна профамма installboot. Итак, после загрузочного сектора управление получает профамма boot. Она уже может не только зафузить саму операционную систему, но и, так как сама является монитором загрузки, позволяет пользователю устанавливать, менять и сохранять различные параметры зафузки. Их boot ищет во втором секторе загрузочного раздела. Как требуют стандарты UNIX, MINIX резервирует первый килобайт каждого диска под загрузочный блок, но под загрузчик используется только 512 байт, поэтому еще 512 байт остается для сохранения параметров. Эти параметры управляют процессом загрузки, кроме того, они передаются самой операционной системе. Настройка по умолчанию предлагает пользователю только один вариант - загрузка MINIX, но можно сделать и более сложное меню, при помощи которого пользователь сможет загрузить, например, другие операционные системы (передав управление загрузочному блоку на другом разделе) или же зафузить MINIX, но с другими параметрами. Кроме того, можно настроить загрузчик так, чтобы он пропускал меню и немедленно начинал загрузку MINIX.

Профамма boot не является частью операционной системы, но для поиска на диске образа операционной системы достаточно естественно опираться на системные структуры данных. По умолчанию boot ищет файл с именем /minix, а если существует каталог /minix/, то ищет в нем самый новый файл. Конфигурационные параметры позволят изменить это поведение и искать файл с любым наперед заданным именем. Подобная степень свободы имеется не всегда, и для больщинства других операционных систем имя зафузочного образа жестко задано. Причина в том, что MINIX - не обычная операционная система, а поощряющая пользователя к ее модификации и созданию новых экспериментальных версий. Осторожность требует того, чтобы оставалась возможность вернуться к прежней версии системы, если новая окажется неработоспособной.

Образ MINIX, который boot зафужает в память, представляет собой не что иное, как слитые вместе скомпилированные части ОС: ядро, менеджер памяти, файловую систему и программу init. Каждая из этих частей содержит в своем начале заголовок, формат которого определяется в файле include/a.out.li. Этот заголовок используется boot для того, чтобы определить, какой объем памяти нужен каждой из составляющих системы под неинициализированные данные. Копия этой информации помещается в упомянутый в предыдущем разделе массив sizes, с той целью, чтобы ядро также знало о положении различных его частей. Области памяти, доступные для загрузочного сектора, самой программы boot и MINIX, зависят от аппаратного обеспечения системы. Кроме того, для некоторых архитектур может потребоваться коррекция кода, чтобы он мог работать, будзи размещенным по тому адресу, куда был загружен. Так как детали процесса зафузки

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

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

2.6.6. Инициализация системы

ос MINIX для компьютеров семейства IBM PC может быть скомпилирована в 16-разрядном режиме (для совместимости со старыми процессорами) или в 32-разрядном, который позволяет достичь большей производительности на процессорах 80386 и старше. В компиляции участвует один и тот же код на С, а то, какая из версий системы будет получена на выходе, зависит от того, является ли сам компилятор 16- или 32-разрядным. Компилятор собственноручно определяет макрос WORD SIZE из файла include/minix/config.h. Первая часть исполняемого кода MINIX написана на языке ассемблера, поэтому для 16- и 32-разрядных версий должен использоваться разный код. В частности, 32-разрядная версия начального кода системы находится в файле mpx386.s. Альтернативная версия для 16-разрядных систем - в mpx88.s. Обе эти версии также включают в себя поддержку различных низкоуровневых операций для ядра. Выбор того, какой из файлов будет использоваться, производится автоматически в файле mpx.s. Этот файл состоит всего из нескольких строк кода и целиком приведен в листинге 2.13.

Листинг 2.13. Как выбирается одна из альтернативных версий ассемблерного кода

#include <minix/config.h> #if WORD SIZE == 2 #inc1ude mpx386.s #else

#include mpx88.s #endif

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

из альтернативных секций исходного кода. Оперируя лишь директивами #if, весь код, как для 32-разрядной, так и для 16-разрядной версий, пришлось бы поместить в один файл. Это не только громоздко, но и приводит к расточению дискового пространства, так как в конкретных установочных пакетах может быть нужна только одна из версий, в то время как вторая могла бы быть помещена в архив или удалена. В последующем обсуждении мы будем рассматривать в качестве примера только 32-битную версию (mpx386.s).

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

Изложив общий порядок обсуждения кода, обратим внимание на важное исключение. Процесс запуска MINIX включает в себя несколько передач управления между функциями на С и ассемблерными процедурами из mpx386.s, поэтому рассмотрение будет вестись в той последовательности, в какой вызываются функции.

После того как процесс начальной зафузки поместил в память код операционной системы, управление передается по метке MINIX (файл трхЗВб.з). Первая инструкция выполняет переход вперед на несколько байтов, чтобы обойти область, занимаемую флагами, которые монитор зафузки использует для получения информации о ядре. Самый важный из флагов сообщает, является ли ядро 16- или 32-битным. Монитор зафузки всегда работает в 16-разрядном режиме, но при необходимости может переключить процессор в 32-разрядный режим перед запуском системы. Кроме трЛ,-монитор зафузки настраивает стек. Значительная часть работы должна делаться ассемблерным кодом: настройка кадра стека, чтобы создать необходимую среду для кода на С, копирование таблиц, описывающих сегменты памяти, и установка различных регистров процессора. Когда эта работа завершена, управление передается функции cstart, написанной на С. Обратите внимание на то, что в ассемблерном коде ссылка на нее выглядит как cstart. Это происходит потому, что компилятор каждое имя функции в таблице