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

Как вы видели ранее, в начале кода kb read вызывается func key, которая определяет различные коды, используемые для управления и отладки. Процедуры вывода отладочной информации из файла dmp.c вызываются, когда обнаруживаются коды клавиш F1 и F2. Первая из них, p dmp, показывает основную информацию обо всех процессах, включая сведения о занятой памяти. Эта подпрограмма вызывается при нажатии F1. Вторая подпрограмма, map dump, при нажатии F2 представляет более подробную информацию о занятой памяти. Функция proc name обеспечивает работу p dmp, определяя имя процесса.

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

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

3.10. Задача системы в MINIX

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

Решением проблемы является системная задача, которая взаимодействует с менеджером памяти и файловой системой при помоши стандартного механизма сообщений и, помимо этого, имеет доступ к структурам памяти ядра. Эта задача, называемая задачей системы, на рис. 2.14 образует второй уровень, работая, как и другие рассмотренные нами задачи. Ее отличие в том, что она не связана с каким-либо устройством. Как и прочие задачи, она реализует интерфейс, но в данном случае это не интерфейс со внешним миром, а связь с самой законспирированной частью системы. Она имеет те же самые привилегии, что и задачи ввода/вывода, и вместе с ними входит в образ ядра, поэтому имеет смысл рассмотреть ее именно здесь, а не в другой главе.

Системная задача воспринимает 19 типов сообщений, перечисленных в табл. 3.20. Основная функция задачи системы, sys task, имеет ту же структуру, что и у других задач. Эта функция получает сообщение, вызывает соответствующую обслуживающую функцию и отправляет ответ. Итак, рассмотрим все эти сообщения и все обслуживающие процедуры.

Сообщение SYS FORK отправляет менеджер памяти, уведомляя им ядро о появлении нового процесса. Ядру необходимо знать об этом, чтобы запланировать новый процесс. В сообщении передаются номера ячеек таблицы процессов, занимаемых родительским и дочерним процессами. Собственные таблицы процессов есть и у менеджера памяти, и у файловой системы, и один индекс k соответствует одному процессу во всех трех таблицах. Таким образом, менеджер памяти может сообщить только номера ячеек родительского и дочернего процесса, а ядро поймет, какие процессы имеются в виду.

Подпрограмма do fork сначала проверяет, не передал ли менеджер памяти ядру неправильную информацию. Для проверки используется макрос isoksusern из файла proc.h, который проверяет, что ячейки в таблице процессов содержат верные данные. Подобные проверки выполняются и другими обслуживающими подпрограммами из system.с. Это чистой воды паранойя, но небольшие дополнительные проверки вреда не принесут. Завершив тестирование, do fork копирует запись из ячейки родительского процесса в ячейку дочернего. При этом необходимы некоторые дополнительные действия. Дочерний процесс освобождается от любых текущих сигналов, и потомок не наследует состояние трассировки родителя. Кроме того, конечно же, вся статистическая информация у дочернего процесса сбрасывается в 0.

Таблица 3.20. Типы сообщений, понимаемые системной задачей (FS - файловая система, ММ - менеджер памяти)

Тип сообщения Отправитель Назначение

После вызова fork менеджер памяти выделяет для нового процесса память. Ядро должно знать, какую память занимает дочерний процесс, чтобы правильно установить у него сегментный регистр. Дать ядру информацию о карте памяти любого процесса позволяет сообщение SYS NEWMAP. Оно может быть использовано и тогда, когда системный вызов Ьгк изменил карту памяти.

Этот тип сообщений обслуживается функцией do newmap, которая сначала копирует новую карту памяти в адресное пространство менеджера памяти. Сама карта в сообщении не содержится, ввиду своего размера. Теоретически, менеджер памяти может сказать, что новая карта памяти расположена по адресу т, а m окажется неправильным адресом. Менеджер памяти не должен так поступать, но ядро не руководствуется только доверием. После проверки карта напрямик копируется в поле р тар записи целевого процесса в таблице процессов. При помощи вызова alloc segments информация извлекается из карты и помещается в поля p reg, содержащие значения сегментных регистров. Эти действия не сложны, но сильно зависят от модели процессора, поэтому вынесены в отдельную функцию.

Сообщение SYS NEWMAP часто используется при нормальной работе системы MINIX. Сходное сообщение, SYS GETMAP, посылается только при первоначальном запуске файловой системы и запрашивает передачу информации о карте памяти в обратном направлении, от ядра к менеджеру памяти. Обслуживается оно функцией do getmap. Коды этой функции и функции обработки предыдущего сообщения сходны, основное различие в том, что отправитель и получатель в вызове phys copy поменяны местами.

Когда процесс делает системный вызов exec, менеджер памяти устанавливает для него новый стек, содержащий аргументы и переменные окружения. Результирующий указатель стека передается ядру при помощи сообщения SYS EXEC, обслуживаемого функцией do exec. Сначала в этой функции делается обычная проверка корректности информации о процессе, а затем проверяется поле PR0C2 сообщения. Это поле используется как признак, трассируется ли процесс, и ничего общего с идентификацией процесса не имеет. Если трассировка в действии, то, чтобы отправить процессу сигнал SIGTRAP, делается вызов cause sig. В нормальной ситуации этот сигнал привел к завершению процесса и выводу дампа ядра. Но в данном случае обычные последствия не имеют места, так как для трассируемого процесса менеджер памяти перехватывает все сигналы за исключением SIGKILL и в ответ на них приостанавливает процесс, позволяя программе-отладчику управлять его дальнейшим выполнением.

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