Глава 18. Сложные темы

В настоящее время существует только одна книга по внутреннему устройству ОС, посвящённая FreeBSD, а именно ''The Design and Implementation of the FreeBSD Operating System'' Маршалла Кёрка МакКузика (Marshall Kirk McKusick) и Джорджа В. Невилле-Нейла (George V. Neville-Neil), ISBN 0-201-70245-2. В ней рассматривается FreeBSD версии 5.X.

Кроме того, большинство общих знаний о UNIX® непосредственно применимо к FreeBSD.

Список относящихся к делу книг можно найти в разделе Руководства Библиография по внутреннему устройству операционной системы.

Пожалуйста, обратитесь к соответствующей статье, в которой вы получите советы относительно того, как это сделать. Ваша помощь более чем приветствуется!

В Хранилище CVS сейчас находятся четыре активно/полуактивно развивающихся ветки FreeBSD. (Более ранние ветки изменяются очень редко, именно поэтому в разработке только четыре активных ветки):

• RELENG_7, также известная как 7-STABLE

• RELENG_8, также известная как 8-STABLE

• RELENG_9, также известная как 9-STABLE

• HEAD, также известная как -CURRENT и 10-CURRENT

HEAD - это не реальный тэг ветки, в отличие от остальных; это просто символьная константа для обозначения ''текущего, не ветвящегося, находящегося в разработке дерева'', то есть -CURRENT.

На данный момент -CURRENT является находящимся в разработке деревом 10.X; ветка 9-STABLE, RELENG_9, отделилась от -CURRENT в сентябре 2011 года года, а ветка 8-STABLE, RELENG_8, отделилась от -CURRENT в августе 2009 года.

Пожалуйста, обратитесь к статье о процессе выпуска релизов.

Да, так и должно быть; как говорит название этой команды, make world выполняет построение всех системных файлов с нуля, так что в итоге можете быть уверены, что получите чистую рабочую систему (вот почему это занимает столько времени).

Если в момент запуска команд make world или make install определена переменная окружения DESTDIR, то вновь создаваемые файлы будут помещены в дерево каталогов. идентичное существующему, с корнем, располагающимся в ${DESTDIR}. Однако некоторые случайные комбинации модификаций совместно используемых библиотек и версий компилируемых программ при исполнении команды make world, могут этому помешать.

Хотя зеркала CVSup обновляются с основного CVSup-сервера каждый час, это обновление может происходить в любой момент в течение часа. Это значит, что некоторые серверы будут иметь более новый код, чем остальные, хотя разница между версиями кода не превышает часа. Если бы для серверов cvsup.FreeBSD.org использовалась одна DNS-запись, то простое перенаправление пользователей на случайно выбранный сервер CVSup, при условии, что CVSup будет запускаться два раза подряд, может привести к сгрузке кода, более старого, чем тот, что присутствует в системе.

Да, это можно делать без скачивания полного дерева исходных текстов с помощью системы CTM.

Команда split(1) в современных BSD-системах имеет опцию -b, позволяющую разрезать файлы на части с точностью до байта.

Вот пример из файла /usr/src/release/Makefile.

ZIPNSPLIT=              gzip --no-name -9 -c | split -b 1392k -

Обратитесь к статье о том, как помочь проекту FreeBSD, чтобы выяснить, как это сделать.

И спасибо Вам за Ваши усилия!

От: Фрэнка Дурды IV (Frank Durda IV) <uhclem@nemesis.lonestar.org>

Если рассматривать на самом низком уровне, то существует несколько портов ввода/вывода, в которые должны выводить информацию все адаптеры PnP, когда компьютер пытается выполнить запрос о наличии установленных адаптеров. Так что, когда запускается процедура определения адаптеров PnP, она выполняет запрос о наличии каких-либо адаптеров PnP, а все такие адаптеры выдают свой номер модели при чтении того же порта ввода/вывода, поэтому процедура определения получит ответ на свой запрос, состоящий из логически наложенных номеров моделей, интерпретируемый как ''да''. В этом ответе по крайней мере один бит будет установлен в единицу. Затем код определения адаптеров может ''выключать'' адаптеры с ID (назначаемыми Microsoft®/Intel®), большими, чем X. Потом следует попытка определить, остались ли ещё адаптеры, отвечающие на запрос. Если ответ 0, то адаптеров с ID, большими чем X, нет. После этого делается попытка определить наличие адаптеров с номерами, меньшими чем X. В заключение происходит запрос на выключение адаптерам, большим чем X - (limit / 4). Запрос повторяется. Применив этот метод полудвоичного поиска границ расположения ID достаточное количество раз, код идентификации найдёт все адаптеры PnP, установленные в данной машине за число итераций, гораздо меньшее, чем может занять перебор 2⁶⁴ возможных вариантов ID.

ID представляет собой два 32-разрядные числа (отсюда число 2⁶⁴) + 8 бит контрольной суммы. Первые 32 бита являются идентификатором производителя. Они никогда не сообщаются, однако часто бывает, что различные типы адаптеров от одного и того же производителя имеют различные 32-битные значения идентификатора производителя. Необходимость в 32 разрядах только для задания производителя адаптера выглядит несколько излишним.

Оставшиеся 32 бита являются серийным номером или чем-либо, делающим этот адаптер уникальным. Производитель не должен выпускать других адаптеров, имеющих то же самое значение этих битов, если, конечно, у них не различаются при этом старшие биты идентификатора производителя. Так что вы можете иметь несколько адаптеров одинакового типа; при этом, 64-разрядные номера будут разными.

Группы по 32 бита не могут быть нулевыми. Это позволяет при логическом объединении OR их номеров получать ненулевое значение во время начального поиска адаптеров.

Как только система определила ID всех адаптеров, она активизирует каждый адаптер, по одному за раз (через те же порты ввода/вывода), и определяет, какие ресурсы требуются данному адаптеру, какие возможные прерывания доступны и т.д. Сканирование и сбор информации происходит по всем адаптерам.

Эта информация соотносится с содержащейся в файлах ECU на диске или в MLB BIOS. Поддержка PnP из ECU и BIOS для аппаратуры на MLB обычно имеет синтетический характер, и периферия не выполняет полностью процедуру настоящего PnP. Однако, используя BIOS и информацию из ECU, процедура инициализации может обнаружить устройства PnP, которые не могут быть найдены другим способом.

Затем устройства PnP опрашиваются ещё раз для назначения им портов ввода/вывода, DMA, IRQ и адресов отображаемой памяти. Теперь устройства должны иметь именно такие настройки и они должны оставаться такими до следующей перезагрузки, хотя нигде не сказано, что вы не можете их менять, когда захотите.

Здесь сделано много упрощений, однако общую идею вы должны уловить.

Microsoft использовала для PnP некоторые порты статуса первого принтера, по их логике, не существует адаптеров, использующих эти адреса для ввода/вывода. Я обнаружил один такой адаптер принтера от IBM, который декодирует запись в порт статуса в момент начального опроса устройств PnP, на что Microsoft ответила ''хулиган''. Так что они выполняют запись в порт статуса принтера для установки адресов, вдобавок используют этот адрес + 0x800, и ещё один порт ввода/вывода используют для чтения, который может располагаться где угодно в диапазоне между 0x200 и 0x3ff.

В версиях FreeBSD, вышедших после февраля 2003 года, есть механизм динамического и автоматического выделения старших номеров для драйверов устройств во время выполнения (смотрите devfs(5)), поэтому в этом нет необходимости.

В ответ на вопрос о других методах размещения каталогов могу сказать, что используемая в настоящее схема не претерпела изменений с того момента, как я реализовал её в 1983 году. Эти соглашения были разработаны для оригинальной файловой системы FFS, и я никогда их не пересматривал. Эта схема хорошо работает, позволяя избежать переполнения групп дорожек. Как некоторые из вас заметили, она работает плохо при поиске. Большинство файловых систем создаются из архивов, которые были созданы с глубиной первого поиска (aka ftw). Это приводит к тому, что их каталоги размещаются на нескольких группах дорожек, создавая наихудший случай для последующего поиска глубиной один. Если бы было известно общее количество каталогов, которые должны быть созданы, выходом было бы создание каталогов в количестве (total / fs_ncg) на каждую группу дорожек. Очевидно, что пришлось бы придумать некоторую эвристику для определения этого числа. Даже при использовании небольшого фиксированного количества, скажем 10, ситуация улучшилась бы на порядок. Чтобы различать операции восстановления от обычных операций (для которых текущий алгоритм, вероятно, является более разумным), вы могли бы использовать объединение в кластеры объёмом до 10, если они помещаются в 10-секундном окне. Как бы то ни было, я думаю, что это большое поле для экспериментов.

Kirk McKusick <mckusick@FreeBSD.org>, сентябрь 1998 года

Вот типичная паника ядра:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x40
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xf014a7e5
stack pointer           = 0x10:0xf4ed6f24
frame pointer           = 0x10:0xf4ed6f28
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 80 (mount)
interrupt mask          =
trap number             = 12
panic: page fault

Если вы видите такое сообщение, просто его воспроизвести и послать нам не достаточно. Здесь важно значение указателя инструкций; к сожалению, его значение зависит от конфигурации ядра. Другими словами, его значение меняется в зависимости от конкретного ядра, которое вы используете. Если вы используете ядро GENERIC одного из снэпшотов, то кто-то ещё может отследить функцию, вызвавшую ошибку, но если вы работаете со специально отконфигурированным ядром, то только вы можете сказать нам, где случилась ошибка.

Вот что вы должны сделать:

Тем не менее, лучшим способом выяснить причину, вызвавшую аварийный останов, является получение аварийного дампа системы, а затем использование kgdb(1) для получения трассировки вызовов в этом дампе.

В любом случае, метод таков:

В процессе выполнения команды make(1) будут построены два ядра, /usr/obj/usr/src/sys/MYKERNEL/kernel и /usr/obj/usr/src/sys/MYKERNEL/kernel.debug. kernel будет установлен как /boot/kernel/kernel, тогда как kernel.debug может быть использован в качестве источника отладочных символов для kgdb(1).

Чтобы включить сброс аварийного дампа, вам нужно отредактировать файл /etc/rc.conf так, чтобы устройство dumpdev указывало на раздел подкачки (или имело значение AUTO). В этом случае скрипты rc(8) будут вызывать команду dumpon(8) для создания аварийных дампов. Также вы можете запустить команду dumpon(8) вручную. После аварийной остановки аварийный дамп может быть получен с помощью программы savecore(8) если значение переменной dumpdev было установлено в /etc/rc.conf, скрипты rc(8) запустят savecore(8) автоматически и поместят аварийный дамп в каталог /var/crash.

Как только вы получили аварийный дамп, вы можете выполнить трассировку вызовов с помощью kgdb(1) таким образом:

% kgdb /usr/obj/usr/src/sys/MYKERNEL/kernel.debug /var/crash/vmcore.0
(kgdb) backtrace

Заметьте, что при этом может быть выведено несколько экранов информации; в идеале вы должны использовать script(1) для их перехвата. При использовании необработанного образа ядра со всей отладочной информацией может быть найдена конкретная строка исходного текста ядра, при достижении которой случилась аварийная остановка. Для выяснения последовательности событий, приведших к аварийному останову, обычно читается трассировка стека снизу вверх. Вы можете также использовать kgdb(1) для вывода значений различных переменных или структур, чтобы выяснить состояние системы во время аварии.

По умолчанию при работе с форматом ELF символы, определённые в исполняемом файле, не доступны динамическому загрузчику. Поэтому при вызове функции dlsym(), которая осуществляет поиск по дескриптору, полученному после вызова dlopen(NULL, flags), желаемый результат достигнут не будет.

Если вы хотите осуществить поиск в выполнимом файле процесса с помощью функции dlsym(), вам нужно скомпоновать выполнимый файл с опцией --export-dynamic компоновщика ELF (ld(1)).

По умолчанию размер адресного пространства ядра для i386 равен 1 Гбайт (2 Гбайт для PAE). Если вы используете FreeBSD в качестве сервера с интенсивной сетевой нагрузкой (скажем, большой FTP или HTTP сервер) или хотите использовать ZFS, то вы можете обнаружить, что этого недостаточно.

Чтобы увеличить доступное пространство, добавьте следующую строку в файл конфигурации ядра и пересоберите его:

options KVA_PAGES=N

Чтобы получить нужное значение для N, разделите желаемый размер адресного пространства (в мегабайтах) на четыре. (Например, для 2 Гбайт это будет 512.)