Предоставил &a.joerg; Перед тем, как читать этот раздел, вы должны усвоить материал раздела о конфигурации ядра. Использование параметров ядра в основном описано в разделе о конфигурации ядра. Там же имеется описание устаревших и параметров в новом стиле. Конечной целью является постепенный перевод всех поддерживаемых параметров ядра к новому стилю, так чтобы для тех, кто корректно выполняют команду make depend в каталоге компиляции ядра после запуска &man.config.8;, процесс построения автоматически принимал модифицированные параметры и перекомпилировал только те файлы, которые необходимы. Удаление старого каталога компиляции при каждом перезапуске &man.config.8;, как это еще происходит сейчас, затем может быть убрано. В своей основе параметр ядра является не более чем определение макроса препроцессора C для процесса компиляции ядра. Чтобы сделать построение полностью настраиваемым через опции процессом, соответствующая часть исходных текстов ядра (или файла .h ядра) должна быть написана с упором на концепцию параметров, то есть чтобы значения, используемые по умолчанию, могли быть переопределены параметрами конфигурации. Это обычно делается примерно так: #ifndef THIS_OPTION #define THIS_OPTION (некоторое значение по умолчанию) #endif /* THIS_OPTION */ Этим способом администратор, задающий другое значение для параметра в своем конфигурационном файле, избегает использования значения по умолчанию и заменяет его новым значением. Более того, новое значение будет подставлено в исходный код во время работы препроцессора, так что это должно быть правильное выражение языка C в контексте использования значения по умолчанию. Также возможно создание параметров, которые не принимают определенного значения, а просто включают или выключают некоторую часть кода, обрамляя его в #ifdef THAT_OPTION [здесь ваш код] #endif Простое упоминание THAT_OPTION в конфигурационном файле (со значением или без него) приведет к включению соответствующего кода. Те, кто знаком с языком C, могут сказать, что все может считаться как config option, там где есть по крайней мере одна строчка #ifdef... Однако вряд ли многие будут писать options notyet,notdef в своих конфигурационных файлах и потом удивляться, почему компиляция ядра не проходит. :-) Более точно, использование уникальных имен для параметров делает очень трудным отслеживание их использования в дереве исходных текстов ядра. В использовании схемы параметров в новом стиле имеется рациональное зерно, когда каждый параметр помещается в отдельный файл .h в каталоге компиляции ядра, который по соглашению называется opt_foo.h. Таким образом, могут быть применены обычные зависимости в Makefile, и утилита make может определить, что нужно перекомпилировать при изменении определенного параметра. Параметры при использовании механизма в старом стиле имеют одно преимущество для локальных изменений или для экспериментальных параметров, которые имеют короткий срок жизни: так как весьма легко добавить новую строку #ifdef к исходному коду ядра, то это уже превращается в параметр конфигурации ядра. В таком случае администратор, использующий параметры таким образом, несет ответственность за знание влияния этого параметра (и может быть, за принудительную перекомпиляцию вручную частей ядра). Как только перевод всех поддерживаемых опций будет сделан, программа &man.config.8; будет выдавать предупреждение о не поддерживаемой опции, появившейся в конфигурационном файле, однако она будет включать ее в файл Makefile ядра. Во-первых, отредактируйте файл sys/conf/options (или sys/<arch>/conf/options.<arch>, например sys/i386/conf/options.i386), и выберите файл opt_foo.h, в котором лучше всего поместить вашу новую опцию. Если имеется что-то, уже похожее на предназначение новой опции, выберите это. Например, опции, изменяющие общее поведение подсистемы SCSI, могут быть помещены в opt_scsi.h. По умолчанию простое упоминание опции в соответствующем файле опций, скажем, FOO, приводит к тому, что ее значение помещается в соответствующий файл opt_foo.h. Это может быть переопределено в правой части правила указанием другого имени файла. Если файла opt_foo.h для предполагаемой новой опции еще нет, придумайте новое имя. Сделайте его значимым и прокомментируйте новый раздел в файле options[.<arch>]. Утилита &man.config.8; автоматически воспримет изменения и создаст этот файл при следующем своем запуске. Большинство опций должно оказаться в заголовочном файле.. Размещение слишком большого количества опций в одном файле opt_foo.h приведет к перестроению слишком большого количества файлов ядра при изменении одной из опций в конфигурационном файле. Наконец, определите, какие файлы ядра зависят от новой опции. Если только вы не только что придумали вашу опцию и она еще нигде не упоминается, то команда &prompt.user; find /usr/src/sys -type f | xargs fgrep NEW_OPTION вам поможет ее найти. Сделайте это и отредактируйте все эти файлы, а также добавьте #include "opt_foo.h" вверху до всех строк #include <xxx.h>. Эта последовательность очень важна, так как опции могут переопределять значения по умолчанию из обычных включаемых файлов, если эти значения по умолчанию даются в форме #ifndef NEW_OPTION #define NEW_OPTION (что-то) #endif в обычном заголовке. Добавление опции, которая переопределяет что-то в системном заголовочном файле (то есть файле, находящемся в каталоге /usr/include/sys/), практически всегда ошибочно. opt_foo.h не может быть включен в те файлы, потому что это изменит заголовки более серьезно, но если он не включен, то в местах его включения может получиться рассогласованность значений для этой опции. Да, такие прецеденты имеют место и сейчас, но это их не оправдывает.