Главная страница  Межпроцессное взаимодействие (состязание) 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 [ 104 ] 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187

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

Как вы видели ранее, в начале кода 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 - файловая система, ММ - менеджер памяти)

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

SYS FORK

Процесс разветвился

SYS NDWMAP

Устанавливает для процесса новую карту памяти

SYS GETMAP

Менеджеру памяти необходима карта памяти процесса

SYS EXEC

Получает указатель стека после вызова exec

SYS XIT

Процесс завершился

SYS GETSP

Менеджеру памяти необходим указатель стека процесса

SYS TIMES

Файловой системе нужна информация о процессорном времени процесса

SYS ABORT

Сбой: MINIX не может продолжить работу

SYS SENDSIG

Посылает процессу сигнал

SYS SIGRETURN

Восстановление после того, как сигнал обработан

SYS KILL

Отправляет процессу сигнал после вызова kill

SYS ENDSIG

Восстановление после сигнала из ядра

SYS COPY

Копирование данных между процессами

SYS VCOPY

Копирование нескольких блоков данных между процессами

SYS GBOOT

Определяет параметры загрузки

SYS MEM

Менеджер памяти требует следующий свободный блок памяти

SYS UMAP

Преобразует виртуешьный адрес в физический

SYS TRACE

Выполняет действия системного вызова ptrace



После вызова 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. В завершение сохраняется командная строка, чтобы процесс можно было



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 [ 104 ] 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187

© 2000 - 2018 ULTRASONEX-AMFODENT.RU.
Копирование материалов разрешено исключительно при условии цититирования.