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

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.