Для того, чтоб заниматься разработками для ядра, желательно
иметь два отдельных компьютера. Один из них предназначен для среды
разработки и исходных кодов, а второй — для запуска тестов
отлаживаемого кода. Второму компьютеру для работы достаточно
иметь возможность выполнять начальную загрузку по сети и монтирование
файловых систем по сети. В этой ситуации, если отлаживаемый код
содержит ошибки и вызовет аварийную остановку системы, то это не
повлечет порчу или утерю исходного кода
.
Второму компьютеру даже не потребуется иметь свой монитор,
достаточно будет соединения асинхронных портов кабелем RS-232 или
соединения при помощи KVM-устройства.
Но так как далеко не у каждого есть два или более компьютеров
под рукой, есть пара способов подготовить иную «живую»
систему для разработки кода для ядра. Один из них — это
разработка в VMWare
или QEmu виртуальной машине
(это лучшее из доступного, после, конечно-же, выделенного для тестов
компьютера).
Прежде всего необходимо иметь в ядре поддержку
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-сервера.
