DragonFlyBSD: компиляция ядра

Алексей Федорчук
2004.12.04

Сборка собственного ядра - один из любимых видов спорта истинных POSIX'ивстов. И пользователи DragonFlyBSD здесь не будут исключением. Не то что в этом есть жизненная необходимость: практически все, что нужно для применения DFBSD в мирных целях (всевозможные файловые системы, поддержка USB-устройств и звуковых карт), либо встроено в ядро Generic, либо реализовано в качестве загружаемых модулей.

Преамбула

И тем не менее, отказываться от сборки собственного ядра нет оснований. Во-первых, ядро Generic предназначено для инсталляции на некую абстрактную машину, и потому включает в себя немерянное количество опций, в конкретной ситуации не нужных - например, поддержку всевозможных сетевых карт (а часто ли в настольной машине их больше одного) и SCSI-контроллеров (а их-то в современном десктопе и того меньше). За счет чего ядро распухает до совершенно неприличных размеров (у меня образ ядра по умолчанию составил более 5 Мбайт).

И при этом в ядре не оказывается по крайней мере одной опции, жизненно важной в современных условиях - поддержки графической консоли. Почему я полагаю эту опцию жизненно важной - будет говориться в следующей заметке (как и о графической консоли вообще). А пока прошу поверить на слово - уже одно это оправдывает толику времени, потраченную на конфигурирование и сборку нового ядра.

Принципы сборки ядра в DFBSD те же, что и во FreeBSD: прямая правка файла конфигурации в текстовом редакторе, сборка посредством команды make с указанием соответствующей цели, инсталляция. И все это очень подробно описано в документации - и в DragonFlyBSD Handbook, и Guidebook, и даже в QuickStart об этом сказано несколько строк (см. ресурсы по теме). Однако коснуться этого вопроса мне представляется необходимым, и по двум причинам.

Во-первых, процесс конфигурирования и сборки ядра в DFBSD имеет некоторую специфику по сравнению с FreeBSD (все-таки другое ядро, и да и ОС совсем другая). А во-вторых, все указанные документы обновляются гораздо медленнее, чем сама система, и описанное в них не всегда точно соответствует современным реалиям.

Маленькое отступление: вообще DragonFlyBSD Handbook требует аккуратного обращения. Большая часть его заимствована из FreeBSD Handbook (что понятно: системы-то схожие, а заново написать такой труд за год, да еще и при ограниченном составе участников проекта, - задача непосильная). И заимствовано подчас механически, без приведения в соответствие со спецификой DFBSD. То же касается и man-страниц: те из них, что посвящены описанию программ, общих в обеих операционках, иногда просто целиком перенесены в DFBSD без всякой коррекции. В следующей заметке я проиллюстрирую это на примере настройки режима консоли. Так что подчас единственно достоверными источниками информации оказываются комментарии в Make-файлах.

В DFBSD (как и во FreeBSD) предусмотрено две ситуации пересборки ядра: в рамках общего "миропостроения" (процедуры make world) и отдельная пересборка. В настоящей заметке я рассмотрю только вторую ситуацию: make world - тема для отдельного разговора.

Получение исходников

Прежде чем приступать к конфигурированию и сборке ядра, не худо было бы разжиться его исходными текстами. На установочном диске DFBSD их нет, единственный источник - это Сеть. Ежедневный снапшот всей системы (включая, конечно, и ядро) доступен на ftp-сервере проекта, но только через cvsup. Пакет этот входит в штатный комплект DFBSD (в числе дополнительных пакетов, устанавливаемых на стадии конфигурирования). Настройка его не сложна, как в дистрибутиве (в каталоге /usr/share/examples/cvsup), так и на странице Download сайта проекта имеются примеры конфигов на разные случаи жизни: для получения исходников только ядра, или всей системы в целом.

По умолчанию полученные через cvsup исходники помещаются в специальный подкатало файловой системы /home/home/dcvs), что не всегда удобно. И потому имеет смысл несколько подредактировать конфиги (они называются dragonfly-cvs-supfile и dragonfly-cvs-sys-supfile - для получения всех исходников или только ядра, соответственно). Мой конфиг для получения всех исходников (плюс дерева портов dfports) выглядит следующим образом:

# All DragonFlyBSD sources, sys, dfports and docs from site
*default host=cvsup.dragonflybsd.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=.
*default delete use-rel-suffix
#*default compress
cvs-src
#cvs-sys
cvs-root
cvs-dfports
#cvs-site

Если нужны только исходники ядра, комментарий со строки cvs-sys следует перенести на строку cvs-src. А строка cvs-site предписывает получать документацию с сайта проекта. Которая обновляется не столь уж часто, и потому в синхронизации не нуждается.

Есть и другой способ получения исходников системы (вместе с ядром): скачать полный их целиком с одного из зеркал проекта - ftp://dragon.bsdtech.com/DragonFly/ (насколько я знаю, единственного). Это тарбалл (src.tar.bz2 размером более 80 Мбайт. Много? Посмотрю, что вы скажете после того, как первый раз закачаете исходники через cvsup - это процесс очень медленный и печальный (хотя в дальнейшем обновление, если проводить его регулярно, много времени не займет.

Принципы конфигурирования

В любом случае - исходники получены и помещены куда следует (в /usr/src - под эту ветвь файловой системы целесообразно выделить самостоятельный раздел объемом около гигабайта - в развернутом виде исходники занимают около 400 Мбайт, и возможно, что потребуется держать две их версии; почему - расскажу в одной из следующих заметок, когда дело дойдет до сборки "мира"). Приступаем к конфигурированию.

Конфиг умолчального ядра GENEREC находится в /usr/src/sys/i386/conf: подкаталог sys - штатное место для исходников ядра, в i386 помещаются части, имеющие отношение к соответствующей архитектуре (вторая поддерживаемая DFBSD архитектура - amd64), conf - место помещения конфигурационных файлов. Кроме GENERIC, там содержится еще файл TINDERBOX (чем он отличается от GENEREC, я не очень понял) и, главное, LINT. Последний - не реальный конфиг, а список всех возможных опций конфигурации. То есть если вам кажется, что в GENERIC чего-то не хватает - ищите в LINT, и обрящите. Благо LINT неплохо структурирован, разделяясь на секции типа - CPU OPTIONS, COMPATIBILITY OPTIONS и так далее, и довольно подробно прокомментирован.

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

$ cp GENERIC MYKERNEL

Имя файла конфигурации ядра по традиции дается символами верхнего регистра. Само по себе оно совершенно произвольно. Однако также традиционно принято, чтобы оно совпадало с именем (hostname) машины - и это действительно удобно. Теперь открываем MYKERNEL в подходящем (то есть любом) текстовом редакторе, не забыв проверить, выключен ли режим переноса строк (впрочем, это общее правило при модификации конфигов). Параллельно (в другой виртуальной консоли) открываем файл LINT - для сверки, так сказать, с картотекой. И еще одна консоль может оказаться не лишней: на нее можно направить вывод команды

$ dmesg | less

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

При редактировании нашего конфига нужно иметь ввиду, что от своего папаши-GENERIC'а он унаследовал из рук вон плохую структуризацию: порядок перечисления опций конфигурирования подчиняется логике, ведомой одному Аллаху. И часто не совпалдает с тем порядком, в котором они следуют в файле LINT. Само по себе это никакого значения не имеет, но доставляет по первости некоторые неудобства.

Смысл многих опций более-менее понятен из а) их названия и б) сопутствующих комментариев. Если тех покажется недостаточным, следует обратиться к файлу LINT: очень возможно, что там описание будет более полным. Лично я считаю, что неясные опции следует вычеркивать безжалостно: скорее всего, они оттого-то и непонятны, что обеспечиваемые ими функции лично мне не нужны. Впрочем, существует и противоположная точка зрения: при сомнении нужно сохранять то, что имеется по умолчанию. Какому пути следовать - каждый решает для себя сам.

И еще: при вычеркивании или вписывании опций следует помнить, что некоторые из них связаны между собой. Большинство таких взаимозависимостей оговорены в комментариях, да и я в своем примере буду останавливаться на известных мне.

Потому что, как обычно, процесс конфигурирования гораздо проще показать, чем описать. Так что я просто дам ниже пример своего файла конфигурации ядра, снабдив соответствующими комментариями. Особо оговаривая обязательность и необязательность опций, а также их взаимосвязи. Унаследованные из GENERIC ненужные (ИМХО) опции закрыты символом комментария (#).

Пример конфигурационного файла

Во первых строках своего письма (сиречь конфига) следует указать, что это за ядро, и с какой целью конфигурировалось - просто для памяти:

#
# ALV -- Мой файл конфигурации ядра DragonFly/i386
#
# Включена поддержка графической консоли
# Выключены все ненужные опции (SCSI, RAID, лишние сетевые карты)

Далее - общие опции, характеризующие машину.

machine   i386

Это - не обозначение процессора, а указание на архитектуру компьютера (то есть синоним Intel-совместимой машины с 32-разрядным процессором.

#cpu   I386_CPU
#cpu   I486_CPU
#cpu   I586_CPU
cpu    I686_CPU

А вот это уже о процессоре. По умолчанию включены все строки - очевидно, что для собственных целей следует оставить только одну (что-то мне подсказывает, что последнюю - это все камни от PentiumPro и выше, включая Athlon и Pentium 4).

ident   ALV

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

maxusers  0

Вопреки названию, эта строка определяет не столько максимальное количество пользователей системы, сколько количество одновременно работающих процессов, открытых файлов, буферов памяти и так далее. Если поставить здесь 0, система будет рассчитывать все это по собственному разумению (и исходя из наличных ресурсов, и сделает это лучше, чем, например, я. Так что если нет глубокого понимания сути этих материй (а у меня, например, нет), оставляем все как есть.

#makeoptions DEBUG=-g

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

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

#options  MATH_EMULATE

Количество слов, посвященных эмуляции сопроцессора, давно превысило возраст (в миллисекундах) последней машины, такового не имеющей. Вычеркиваем.

options INET #options INET6

Поддержка IP (Internet Protocol) версий 4 и 6, соответственно. Первая строка необходима, вторая пока, скорее всего, - нет (IPv6 в настоящее время мало где поддерживается).

options   FFS  
options   FFS_ROOT

Поддержка FFS (нативной файловой системы DFBSD) и загрузки с оной. Очевидно, ни без того, ни без другого не обойтись.

options SOFTUPDATES

Поддержка механизма Soft Updates - очень полезной штуки, повышающей как надежность файловых операций, так и, парадоксальным образом, их быстроту (подробности можно посмотреть здесь. Практически необходимо.

options   UFS_DIRHASH

Опция, зело способствующая скорости доступа к содержимому каталогов (особенно с большим количеством файлов). Так что не помешает.

options   MFS 
#options  MD_ROOT

Поддержка файловой системы в оперативной памяти (mfs - Memory File System) и возможности загрузки с RAM-диска. Первая строка - хоть и не необходима, но очень полезна, обеспечивая не только возможность размещения на mfs каталогов временной надобности (типа tmp и /usr/obj), но и, например, доступ к iso-образам CD как к реальным устройствам (аналогично loopback-устройствам в Linux). Загрузка же в RAM-диска (диска в оперативной памяти) мне лично не нужна.

options   NFS  
#options  NFS_ROOT

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

#options  MSDOSFS  
#options  CD9660  
#options  CD9660_ROOT 

Поддержка FAT всякого рода, файловой системы CD-дисков (iso9660) и возможности загрузки с последних. При эпизодическом использовании во включении их нет необходимости (также как отпадает необходимость внесения из LINT строки options EXT2FS для доступа к файловой системе Linux). Все эти функции обеспечиваются собираемыми по умолчанию модулями, активизируемыми при обращении с соответствующими устройствами. А отключение опции CD9660_ROOT загрузке с CD при должных установках BIOS не препятствует, требуясь только при загрузке через loader.

options   PROCFS

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

options   COMPAT_43

Опция совместимости с 43BSD (не путать с FreeBSD 4.3). Необходима - без нее ядро не соберется.

#options  SCSI_DELAY=15000

Задержка перед опробованием SCSI-устройств. Вам нужно? Я так обхожусь.

options   UCONSOLE   

Эта строка обеспечивает захват системной консоли любым пользователем. В BSD-системах, в отличие от Linux, первый виртуальный терминал сохранил рудимент древней консоли - на него по умолчанию сыпятся системные сообщения. Так вот, эта опция позволяет в принципе перенаправить их, например, в окно эмулятора терминала Иксового сеанса. Теоретически могу представить себе ситуацию, когда это нужно (хотя практически попадать в нее не приходилось).

#options  USERCONFIG  
#options  VISUAL_USERCONFIG

Включение редактора конфигурации ядра, вызываемого при загрузке, и визуальной оболочки для него. Может пригодиться при тестировании всякого железа. Я ни разу потребности не ощутил.

#options  KTRACE

Трассировщик для отладки ядра. Как-то обхожусь - и пока жив.

options   SYSVSHM

Поддержка разделяемой памяти в стиле System V. Требуется некоторым программам. В частности, Иксы без этой опции ругаются при старте (но тем не менее работают). Лучше, однако, оставить.

#options  SYSVMSG 
#options  SYSVSEM 

Как ехидно сказано в Handbook'е, не делают ничего, кроме как добавляют по несколько сот байт кода в ядро. Посему подлежат исключению.

#options  P1003_1B
#options  _KPOSIX_PRIORITY_SCHEDULING

Расширения для систем реального времени. Я в этом ничего не понимаю - и потому вычеркиваю.

#options  ICMP_BANDLIM

Опция предназначена, в частности, для защиты от DoS-атак, что важно для сервера, но вряд ли актуально для десктопа.

options   KBD_INSTALL_CDEV
#options  AHD_REG_PRETTY_PRINT

Смысл этих опции остается для меня загадкой.

Далее идут блоки поддержки SMP и отладки. Многопроцессорной машины у меня нет, и отладкой ядра я не занимаюсь, поэтому они закомментированы.

# To make an SMP kernel, the next two are needed
#options  SMP
#options  APIC_IO
# Debugging for Development
#options  DDB
#options  DDB_TRACE
#options  INVARIANTS
#options  INVARIANT_SUPPORT

А теперь начинается самый большой раздел - поддержка всякого рода устройств. Он же - и требующий наибольшего внимания. Не потому, что остальные разделы не важны, просто здесь легче всего допустить ошибку.

device   isa
#device   eisa
device   pci

Поддержка одноименных системных шин. Очевидно, что вторая строка не нужна, третья необходима. Как ни странно, необходимой оказывается и первая строка - даже если в машине нет ни одного ISA-разъема: шина-то есть, и через нее работают мышь и клавиатура. И для syscons она требуется.

# Floppy drives
#device   fdc0 at isa? port IO_FD1 irq 6 drq 2
#device   fd0  at fdc0 drive 0
#device   fd1  at fdc0 drive 1

Поддержка флоппи-дисководов. У меня такового давно нет - и потому ремарка, ремарка и еще раз ремарка.

# ATA and ATAPI devices

Секция поддержка ATA-устройств.

#device   ata0 at isa? port IO_WD1 irq 14
#device   ata1 at isa? port IO_WD2 irq 15

Поддержка старых IDE-контроллеров, ныне давно вымерших.

device   ata
device   atadisk     # ATA disk drives
device   atapicd     # ATAPI CDROM drives

Общая поддержка ATA-интерфейса, ATA-винчестеров и ATAPI-CD. Необходимо, если только не все накопители в системе - SCSI.

#device   atapifd     # ATAPI floppy drives
#device   atapist     # ATAPI tape drives

Поддержка ATAPI-floppy (сиречь Zip и LS-приводов) и ATAPI-стриммеров, соответственно. Необходимо, если есть соответствующие устройства.

#device   atapicam

Эмуляция SCSI-шины через ATA-интерфейс. До недавнего времени требовалась для записи дисков CD-R/RW утилитой cdrecord. Ныне последняя работает напрямую с ATA-приводами. И к тому же в BSD-системах испокон веков для этой цели существовала утилита burncd, также ни в какой эмуляции SCSI не нуждающаяся. Впрочем, для записи DVD-R/RW эмуляция SCSI вроде бы по прежнему нужна - за отсутствием соответствующего дивайса информации на сей счет не имею (но буду за таковую признателен).

options   ATA_STATIC_ID

Статическая нумерация дисковых устройств в зависимости от их положения на IDE-канале (а не в порядке подключения). Нужно или нет - вопрос привычки (я привык).

# SCSI Controllers

Секция поддержки конкретных SCSI-контроллеров. У меня нет ни одного, и потому все ее содержимое вычеркнуто.

# SCSI peripherals

А вот это - общая поддержка SCSI-устройств, и без этой секции, как сейчас станет ясным, в современных условиях не обойтись.

device   scbus
device   da

Общая поддержка SCSI-шины и SCSI-дисков (da - Direct Access). Практически необходимы - в Unix'ах все напоители, не являющиеся IDE, имеют обыкновение прикидываться SCSI-дисками. То есть эти опции необходимы для использования обычных USB-флешек и внешних USB-винчестеров. А также - Zip-приводов на параллельном порту, но это уже не очень актуально.

#device   sa    # Sequential Access (tape etc)
#device   cd    # CD

Поддержка стриммеров и CD ROM со SCSI-интерфейсом. У кого есть - сами знают, что нужно.

Еще одна строка из того же блока -

device   pass

Она нужна, насколько я знаю, для эмуляции SCSI через ATA, о чем говорилось выше.

Далее идут две секции, посвященные RAID-контроллерам:

# RAID controllers interfaced to the SCSI subsystem

и

# RAID controllers

За отсутствием оных у меня вычеркнуты на корню.

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

# atkbdc0 controls both the keyboard and the PS/2 mouse
device   atkbdc0 at isa? port IO_KBD
device   atkbd0 at atkbdc? irq 1 flags 0x1
device   psm0 at atkbdc? irq 12

Это - поддержка контроллера клавиатуры, собственно клавиатуры как таковой и мыши PS/2. Необходимо.

device   vga0 at isa?

Поддержка стандартного VGA-режима. Необходимо, так как с точки зрения консоли крутейший GeForce не более чем обычный VGA-адаптер.

# splash screen/screen saver
pseudo-device splash

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

options   SC_HISTORY_SIZE=1000

Максимальный размер буфера экрана (в строках) - той истории, которую можно пролистать при нажатой включенной клавише ScrollLock (не путать с буфером истории команд, он определяется настройками шелла). Мне умолчальных 200 строк явно мало.

options   SC_MOUSE_CHAR=0x3

Переопределение кодом для т.н. графического курсора мыши в консоли. Требуется, если в качестве кодировки вывода используется KOI8 (иначе текст на экране портится). Впрочем, того же результата можно добиться внесением соответствующей строки в файл /etc/rc.conf (см. соответствующий материал), кому что проще.

options   VESA

Поддержка видеорежимов VESA-стандарта (все современные карты с ним совместимы). Требуется, если есть желание использовать нестандартные разрешения (точнее, плотность символов) в текстовой консоли.

options   SC_PIXEL_MODE

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

#options   MAXCONS=10

Опция (также перенесенная из LINT, сохранена (с ремаркой) в назидание. Устанавливает ограничение числа виртуальных консолей (умолчальное значение - 16, из них в свежеустановленной системе активизировано 8). Во FreeBSD использование ее не влекло никогда вреда ни малейшего. В DFBSD же, собрав ядро с этой опцией, я после рестарта получил ровно две виртуальные консоли - и ни одной свободной (то есть и Иксы было не запустить). Причины остались неизвестными - по вычеркивании опции и пересборке ядра все пришло в норму.

device   agp

Поддержка шины agp. Сейчас (пока еще?) - необходимость.

device npx0 at nexus? port IO_NPX irq 13

Поддержка "железного" сопроцессора - необходима, даже если такового не имеется, без этой опции ядро отказывается компилироваться.

device   apm0

Поддержка расширенного управления питанием (APM). Насколько понимаю, при наличие ACPI (собираемого в виде модуля) не нужна. Или ошибаюсь?

# PCCARD (PCMCIA) support
device   pccard
device   cardbus
device   cbb
device   pcic

Поддержка PC-карт (они же - PCMCIA): общая (pccard), для новых PCI-карт (cardbus и cbb), моста ISA/PCCARD для старых ISA-карт (pcic), в числе последних - "железные" модемы. Требуется на ноутбуках (если соответствующие карты имеются).

# Serial (COM) ports
device   sio0 at isa? port IO_COM1 flags 0x10 irq 4
device   sio1 at isa? port IO_COM2 irq 3
device   sio2 at isa? disable port IO_COM3 irq 5
device   sio3 at isa? disable port IO_COM4 irq 9

Поддержка последовательных портов. Первые две строки - для внешних, вторые - если имеется внутренний модем, определяемый как COM3 или COM4.

# Parallel port
device   ppc0 at isa? irq 7
device   ppbus   # Parallel port bus (required)
device   lpt    # Printer
#device   plip   # TCP/IP over parallel
device   ppi    # Parallel port interface device
#device   vpo    # Requires scbus and da

Поддержка параллельного порта. Подробности - в комментариях в LINT, мне описывать лениво за неактуальностью. Только о последней строке: это тот самый Zip-привод на параллельном порту, который прикидывается SCSI-диском и потому требует поддержки scbus и da.

Теперь пойдет подразмел о сетевых картах. Карт этих, как известно, много, и подраздел очень длинный. Однако реально нужно только ниже перечисленное.

device   miibus

Эта опция необходима для многих сетевых карт, а также и для использования модемного соединения. Так что скорее всего, нужна.

device   fxp

Поддержка чипсетного сетевого адаптера от Intel ICH#. Эту строку следует заменить на ту, что соответствует наличной сетевой карте (какой - смотрим в выводе dmesg или ifconfig.

pseudo-device loop

Сетевое loopback-устройство. Требуется для "внутримашинной" сети - например, запуска web-сервера.

pseudo-device ether

Поддержка Ethrnet-соединения. Необходимо.

pseudo-device ppp  1
pseudo-device tun

Поддержка "ядерного" (через демон ppd) или пользовательского (через программу ppp) соединения точка-точка; одно из двух необходимо для модемного подключения.

pseudo-device pty

Поддержка псевдотерминалов. Необходима, так как требуется программам типа telnet, а также Иксовым эмуляторам терминалов.

pseudo-device md

Поддержка Memory Disks - практически необходима, в сочетании с поддержкой MFS (о которой говорилось выше).

pseudo-device bpf    #Berkeley packet filter
pseudo-device crypto   # core crypto support, used by wlan

Обе опции, насколько я понимаю, необходимы.

И теперь два последниз блока - о USB и Firewire.

device   uhci   # UHCI PCI->USB interface
device   ohci   # OHCI PCI->USB interface
device   usb    # USB Bus (required)

Общая поддержка USB (третье) и типов USB-контроллеров для USB 2.0. Третья строка необходима в любом случае, одна из двух первых - также.

device   ugen

Поддержка всего класса USB-устройств. Необходимо.

device   uhid

"Гуманистический" интерфейс для взаимодействия с человеком. Включает поддержку USB-клавиатур и мышей.

#device   ukbd
device   ums

То же самое, но по отдельности - клавиатуры и мыши, соответственно.

device   ulpt
device   uscanner

Принтеры и сканеры с USB-интерфейсом, соответственно.

device   umass

Внешние накопители с USB-интерфейсом - флешки, внешние винты и, как ни странно, цифровые камеры (вернее, их встроенные накопители). Прикидываются SCSI-дисками и потому требуют поддержки scbus и da.

# USB Ethernet, requires mii
#device   aue    # ADMtek USB ethernet
#device   cue    # CATC USB ethernet
#device   kue    # Kawasaki LSI USB ethernet

Сетевые USB-соединения. За отсутствием оных, ничего сказать не могу.

# FireWire support
#device   firewire 
#device   sbp  
#device   fwe 

Общая поддержка Firewire, соответствующих накопителей и соединений. Увы - более ничего по этому поводу не знаю.

Файл конфигурации можно дополнить еще некоторыми опциями, которых нет в GENERIC - их потребуется перенести из LINT. Например, не запрещается встроить в ядро поддержку звука, вписав строку типа

device   pcm

обеспечивающую работу многих карт для PCI-шины (например, SB AWE 137X). Впрочем, делать это не обязательно - поддержка звука прекрасно осуществляется и загружаемыми модулями.

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

pseudo-device ccd  4

где цифра соответствует их количеству (псевдоустройств, не дисков - то есть в домашних условиях можно ограничится единицей). Есть и другой способ создания программного RAID'а - механизм Vinum, также поддерживаемый опцией ядра (или модульно), но я им не пользовался и потому за него говорить не буду. Как и за многие другие опции, перечисленные в файле LINT: надеюсь, те, кто имел с ними дело, помогут мне пополнить приведенное описание.

Настройка условий компиляции

Конфигурирование закончено, можно переходить к сборке? Да, но не совсем. Потому что предварительно не худо определить условия, при которых эта самая сборка будет происходить. А условия эти описываются в специальном конфиге - /etc/make.conf. В свежеинсталлированной системе такого не имеется - его нужно скопировать с прототипа

$cd /etc/defaults/make.conf /etc/make.conf

и отредактировать по своим потребностям.

Настройки /etc/make.conf влияют не только на сборку ядра, но и "мира", а также портов. Поэтому к нему еще придется возвращаться. А пока - только о тех его параметрах, которые важны для компиляции ядра. И в порядке их логики, а не расположения строк в /etc/make.conf.

Перво-наперво, это версия компилятора. Перво-наперво - потому, что от этого зависят все остальные параметры. Ибо gcc-2.95, используемый в DFBSD по умолчанию, не позволяет, например, оптимизировать под современные процессоры - время для него остановилось на i686. Так что определяем переменную

CCVER?=gcc34

и двигаемся дальше - теперь уже именно к процессору. Тип его задается переменной

CPUTYPE=значение

устанавливающей флаги -mcpu=значение и -march=значение. Из значений допустимы:

# Intel x86 architecture:
#  (AMD CPUs)  k7 k6-2 k6 k5
#  (Intel CPUs) p4 p3 p2 i686 i586/mmx i586 i486 i386

из чего и выбираем в соответствие с реалиями (AMD64, насколько я понимаю, принадлежит уже к другой, не-i386-й, архитектуре). Можно запретить установку флага -march=значение, определив переменную

NO_CPU_COPTFLAGS=true

но оно нам нужно? Ведь на более слабой машине, чем стоит на нашем столе мы свое ядро запускать не собираемся, верно?

Теперь следует определить уровень оптимизации - для ядра он задается переменной COPTFLAGS= значение. Принятый по умолчанию - -O1, то есть самый низкий (ниже только -O0, или отсутствие оптимизации вообще. Для FreeBSD (и gcc-2.95) это было абсолютно верно - хотя иногда и удавалось собрать ядро при флаге -O2, но это не гарантировалось (а выполнить make world во Free мне, например, вообще не удалось ни разу при оптимизации выше -O1). Для DFBSD (и, повторяю, gcc 3.4.X) есть информация, что ядро может быть собрано и при -O3. Впрочем, для первого раза будем осторожны, ограничившись таким значением:

COPTFLAGS= -O2 -pipe

Тем более, что дает ли прирост быстродействия уровень O3 - вопрос спорный.

Из прочих переменных, имеющих отношение к сборке ядра, заслуживает внимание такая:

#NO_MODULES= true

Если снять с этой строки комментарий, то при компиляции ядра модули поддержки функций, таковую допускающих, собираться не будут. Хорошо это или плохо - вопрос спорный. Во FreeBSD я всегда жестко встраивал нужные мне функции в ядро, запрещая сборку модулей - дабы не загромождать каталог /boot множеством заведомо ненужных файлов. Однако идеология архитектуры DFBSD (перенос драйверов устройств в userland, то есть пользовательское пространство памяти) как бы подталкивает к модульной поддержке всего, чего только можно - даже поддержку всех файловых систем, кроем нативной UFS (очевидно, что FS, на которой лежит корень файлового древа, модульно поддерживаться не может). И здесь я эту строку оставил закрытой комментарием.

Процесс пошел

Вот теперь можно и приступать к сборке. Для чего всего-то и потребуется:

  • получить права суперпользователя (впрочем, без них, понятное дело, не обойтись было и при редактировании файла конфигурации и /etc/make.conf);
  • перейти в общий корень дерева исходников - каталог /usr/src (именно сюда, а не в /usr/src/sys);
  • дать команду make< с указанием цели (target)./li>

Какова цель команды make? Все документы, существующие на данный момент, дружно указывают в качестве таковой buildkernel. И все они не правы. Потому что в ответ на команду

$ make buildkernel KERNCONF=MYKERNEL

последует сообщение об ошибке и предложение сначала выполнить операцию make buildworld. И потому приходится обратиться к комментариям в файле /usr/src/Makefile - благо он содержит исчерпывающие указания на сей счет (и на счет допустимых target'ов при сборке ядра и "мира" вообще). Так вот, из этого авторитетного источника следует, что для сборки одного только ядра, отдельно от всего остального "мира", должна использоваться команда

$ make nativekernel KERNCONF=MYKERNEL

Нужно только не забыть указать в качестве значения опции KERNCONF имя файла конфигурации собственного ядра - иначе благополучно пересоберется ядро GENERIC. После чего с чистой совестью отправляемся курить - на современных машинах процесс будет длиться минут 10 (честно говоря, время не засекал). По завершении чего свежесобранное ядро вместе с принадлежащими ему модулями должны быть инсталлированы - для этого существует команда

$ make installkernel KERNCONF=MYKERNEL

(опять же не забываем про параметр KERNCONF=MYKERNEL). Она запишет новый образ ядра в файл /kernel (корневой каталог - штатное для него место в DFBSD), старый образ ядра переименует в /kernel.old (запомним - при неудачной сборке он может понадобиться), новые модули разместит в каталоге /modules, а существовавшие ранее - в переименованный каталог /modules.old. И теперь остается только перезагрузиться.

Что дальше

А дальше остается только радоваться жизни (и новому ядру). Правда, для полного счастья нужно еще научиться обращаться с модулями ядра - ведь многие функции в описанной выше конфигурации доступны именно через них.

Некоторые модули никакого особого обращения не требуют. Так, модули поддержки чуждых файловых систем (MSDOS, iso9660, ext2fs) загружаются автоматически при их монтировании. В чем легко убедиться командой kldstat(она предназначена для просмотра списка загруженных модулей) до

$ kldstat                  16:43 ttyv0
Id Refs Address Size  Name
1 6 0xc0100000 2e25fc kernel
2 1 0xc03e3000 11494 fire_saver.ko
3 2 0xc03f5000 1b300 snd_pcm.ko
4 1 0xc0411000 57e4  snd_ich.ko
5 1 0xc0417000 58718 acpi.ko

и после

$ kldstat                  16:43 ttyv0
Id Refs Address Size  Name
1 6 0xc0100000 2e25fc kernel
2 1 0xc03e3000 11494 fire_saver.ko
3 2 0xc03f5000 1b300 snd_pcm.ko
4 1 0xc0411000 57e4  snd_ich.ko
5 1 0xc0417000 58718 acpi.ko
7 1 0xd7871000 9000  cd9660.ko

монтирования, например, CD-диска. Правда, по размонтировании файловой системы такой модуль столь же автоматически же не выгружается. Но это (при необходимости) легко проделать командой

$ kldunload cd9660

удаляющей ранее загруженные (любым способом) модули из памяти.

Другие модули (например, звуковых устройств) такой роскоши не подразумевают - при потребности их следует загрузить руками. Это делается командой kldload имя_модуля. Например, последовательностью

$ kldload snd_pcm
$ kldload snd_ich

Мы обеспечиваем работу чипсетного аудио от Intel ICH#.

Наконец, модули, нужные перманентно (те же звуковые) можно загружать автоматически при старте системы, как это было описано в заметке о загрузке.

Обновлено: 12.03.2015