2. Подготовка
Пред. |  | След.

## 2. Подготовка

Для того, чтоб заниматься разработками для ядра, желательно иметь два отдельных компьютера. Один из них предназначен для среды разработки и исходных кодов, а второй — для запуска тестов отлаживаемого кода. Второму компьютеру для работы достаточно иметь возможность выполнять начальную загрузку по сети и монтирование файловых систем по сети. В этой ситуации, если отлаживаемый код содержит ошибки и вызовет аварийную остановку системы, то это не повлечет порчу или утерю исходного кода . Второму компьютеру даже не потребуется иметь свой монитор, достаточно будет соединения асинхронных портов кабелем RS-232 или соединения при помощи KVM-устройства.

Но так как далеко не у каждого есть два или более компьютеров под рукой, есть пара способов подготовить иную «живую» систему для разработки кода для ядра. Один из них — это разработка в VMWare или QEmu виртуальной машине (это лучшее из доступного, после, конечно-же, выделенного для тестов компьютера).

### 2.1. Настройка системы для разработки

Прежде всего необходимо иметь в ядре поддержку `INVARIANTS`. Добавьте следующие строки в файл конфигурации ядра:

options INVARIANT_SUPPORT options INVARIANTS

Для большей информативности при отладке включите поддержку WITNESS, которая будет предупреждать вас в случае возникновения взаимоблокировок:

options WITNESS_SUPPORT options WITNESS

Также включите отладочные символы, если планируете выполнять отладку по дампам аварийных отказов

makeoptions DEBUG=-g

Установка отладочного ядра обычным способом (`make installkernel`) не даст привычного результата: файл ядра будет называться `kernel.debug` и будет находиться в `/usr/obj/usr/src/sys/KERNELNAME/`. Для удобства, отладочное ядро необходимо скопировать в `/boot/kernel/`.

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

options KDB options DDB options KDB_TRACE

Для автоматического запуска отладчика ядра после возникновения паники может понадобиться установить переменную sysctl:

debug.debugger_on_panic=1

Паники системы будут происходить, поэтому уделите внимание кэшу файловой системы. Обычно, при включенном механизме softupdates, последняя версия файла может быть утеряна если паника произошла раньше сбрасывания кэша на устройство хранения. Выключение механизма softupdates (посредством монтирования файловой системы с опцией «sync») значительно сказывается на производительности и, опять-же, не гарантирует целостности данных. Как компромисс, можно сократить задержки сбрасывания кэша механизма softupdates. Есть три переменных sysctl, значения которых необходимо изменить (лучше всего — прописав их в `/etc/sysctl.conf`):

kern.filedelay=5 kern.dirdelay=4 kern.metadelay=3

Значения этих переменных — секунды.

Для отладки паник ядра необходимы дампы памяти. Так как паника ядра может «сломать» файловую систему, дамп сначала сохраняется в «сырой» раздел. Обычно, это своп-раздел. Поэтому, размер своп-раздела должен быть не меньше размера ОЗУ компьютера. При последующей загрузке дамп копируется в обычный файл. Это происходит сразу-же после проверки и монтирования файловых систем, но перед активированием раздела свопа. Такое поведение контролируется следующими переменными `/etc/rc.conf`:

dumpdev="/dev/ad0s4b" dumpdir="/usr/core"

Переменная `dumpdev` указывает на раздел подкачки, а `dumpdir` сообщает системе куда перемещать дамп ядра при следующей загрузке.

Сохранение дампа ядра — процесс медленный, и, если у вашего компьютера много оперативной памяти (>256M) и если паники случаются часто, то ожидание сохранения дампов может начать раздражать (вспомним, что над дампом происходит две операции: сохранение в своп-файл и перемещение на файловую систему). В таком случае может оказаться удобным ограничивание объема используемой системой памяти путем установки переменной в `/boot/loader.conf`:

hw.physmem="256M"

Если паники случаются часто и размер файловых систем большой (или же вы просто не доверяете softupdates и фоновой проверке файловых систем), рекомендуется отключить фоновую проверку файловых систем посредством установки переменной в `/etc/rc.conf`:

background_fsck="NO"

В этом случае файловые системы будут проверяться только при необходимости. Также заметьте, что в случае использования фоновой проверки, новая паника может случиться в то время, когда проверяются диски. Другими словами, наиболее безопасный способ — не иметь много локальных файловых систем, а использовать второй компьютер в качестве NFS-сервера.

### 2.2. Начало проекта

Для написания нового класса GEOM необходимо создать поддиректорию в любой доступной пользователю директории. Совсем не обязательно, чтоб ваш модуль изначально размещался в `/usr/src`.

### 2.3. Makefile

Правилом хорошего тона является создание `Makefile`-ов для каждого нетривиального проекта, примером которого конечно-же является создание модулей ядра.

Создание `Makefile` — дело не сложное благодаря исчерпывающему набору вспомогательных средств, предоставляемых системой. В вкратце, вот как должен выглядеть `Makefile` для модуля ядра:

SRCS=g_journal.c KMOD=geom_journal .include <bsd.kmod.mk>

Этот `Makefile` (с измененными именами файлов) подойдет к любому модулю ядра. Класс GEOM может размещаться в одном единственном модуле ядра. Если для сборки вашего модуля требуется больше, чем один файл, то перечислите их имена, разделенные пробельными символами, в переменной `SRCS`.

Пред. |  | След.
Создание класса GEOM | Начало | 3. Программирование в ядре FreeBSD

Этот, и другие документы, могут быть скачаны с http://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите в рассылку <doc@FreeBSD.org>.