Алексей Федорчук
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#.
Наконец, модули, нужные перманентно (те же звуковые) можно загружать автоматически при старте системы, как это было описано в заметке о загрузке.
