Что именно делает ядро Linux "сделать defconfig"?

Я могу использовать следующую команду для создания ядра Linux .config файл на основе заданной архитектуры по умолчанию для пользовательской платы на основе ARM:

ARCH=arm make defconfig KBUILD_DEFCONFIG=var_som_mx6_android_defconfig

Я думал, что эта команда более или менее копирует ./arch/arm/configs/var_som_mx6_android_defconfig to ./.config. Однако в результате .config файл не совсем копия:

$ diff --unified arch/arm/configs/var_som_mx6_android_defconfig  .config
--- arch/arm/configs/var_som_mx6_android_defconfig  2017-01-20 12:10:51.891515984 -0800
+++ .config 2017-01-26 15:31:29.000000000 -0800
@@ -407,6 +407,7 @@
 CONFIG_ARM_ERRATA_751472=y
 CONFIG_ARM_ERRATA_794072=y
 CONFIG_ARM_ERRATA_761320=y
+CONFIG_ARM_ERRATA_845369=y
 # CONFIG_ARM_ERRATA_753970 is not set
 CONFIG_ARM_ERRATA_754322=y
 # CONFIG_ARM_ERRATA_754327 is not set
@@ -2683,7 +2684,6 @@
 CONFIG_AUTOFS4_FS=y
 CONFIG_FUSE_FS=y
 # CONFIG_CUSE is not set
-CONFIG_AUFS_FS=y

 #
 # Caches
@@ -2759,6 +2759,21 @@
 # CONFIG_PSTORE is not set
 # CONFIG_SYSV_FS is not set
 # CONFIG_UFS_FS is not set
+CONFIG_AUFS_FS=y
+CONFIG_AUFS_BRANCH_MAX_127=y
+# CONFIG_AUFS_BRANCH_MAX_511 is not set
+# CONFIG_AUFS_BRANCH_MAX_1023 is not set
+# CONFIG_AUFS_BRANCH_MAX_32767 is not set
+CONFIG_AUFS_SBILIST=y
+# CONFIG_AUFS_HNOTIFY is not set
+# CONFIG_AUFS_RDU is not set
+# CONFIG_AUFS_PROC_MAP is not set
+# CONFIG_AUFS_SP_IATTR is not set
+# CONFIG_AUFS_SHWH is not set
+# CONFIG_AUFS_BR_RAMFS is not set
+# CONFIG_AUFS_BR_FUSE is not set
+CONFIG_AUFS_BDEV_LOOP=y
+# CONFIG_AUFS_DEBUG is not set
 CONFIG_NETWORK_FILESYSTEMS=y
 CONFIG_NFS_FS=y
 CONFIG_NFS_V3=y

Я не понимаю, откуда берутся дополнительные строки, и я всегда находил внутреннюю работу конфигурации ядра, makefiles и build скрипты трудно понять. Может ли кто-нибудь объяснить, где эти строки в .config может быть?

2 ответов


мотивация

на .config файл не просто скопирован с вашего . Мотивация для хранения defconfig в таком формате следующий: в defconfig мы можем указать только параметры с нестандартными значениями (т. е. параметры, которые мы изменили для нашей платы). Таким образом, мы сможем сохранить его маленьким и ясным. Каждая новая версия ядра приносит кучу новых опций, и таким образом нам не нужно обновлять наш defconfig файл каждый раз новые версии ядра. Кроме того, следует отметить, что ядра система сборки сохраняет очень конкретный порядок опций в defconfig файл, поэтому лучше избегать его изменения вручную. Вместо этого вы должны использовать make savedefconfig правило.

упрощенное объяснение

, когда .config файл генерируется, система сборки ядра проходит через все Kconfig файлы (включая все подкаталоги), просмотрев все варианты в этих Kconfig файлы:

  • если опция упоминается в defconfig, build system ставит эту опцию в .config с выбранным значением в defconfig
  • если опция не упоминается в defconfig, build system ставит эту опцию в .config используя значение по умолчанию, указанное в соответствующем Kconfig

Регистрация скрипты/kconfig / Makefile и скрипты / kconfig / conf.c файлы, чтобы увидеть, как это на самом деле делается.

более точное и подробное объяснение

с "Kbuild: система сборки ядра Linux" Хавьера Мартинес!--65-->:

Определения Конфигурации Символов: Kconfig файлы

символы конфигурации определяются в файлах, известных как Kconfig файлы. Каждый Kconfig файл может описывать произвольное количество символов, а также может включать (источник) другие Kconfig файлы. Цели компиляции, которые создают меню конфигурации параметров компиляции ядра, такие как make menuconfig читать эти файлы, чтобы построить древовидную структуру. Каждый каталог в ядро имеет одно Kconfig это включает в себя Kconfig файлы из подкаталогов. В верхней части каталога исходного кода ядра есть Kconfig файл, который является корнем дерева опций. The menuconfig (scripts/kconfig/mconf), gconfig (scripts/kconfig/gconf) и другие цели компиляции вызывают программы, которые начинаются с этого корня Kconfig и рекурсивно читать Kconfig файлы, расположенные в каждом подкаталоге для создания своих меню. Какой подкаталог посетить также определяется в каждом Kconfig файл, а также зависит от значения символов config, выбранные пользователем.

Хранение Значения Символов:

все значения символов конфигурации сохраняются в специальном файле .config. Каждый раз, когда вы хотите изменить конфигурацию компиляции ядра, вы выполняете цель make, такую как menuconfig или xconfig. Эти читают Kconfig файлы для создания меню и обновления значений символов конфигурации, используя значения, определенные в . Кроме того, эти инструменты обновите .config файл с новыми параметрами, которые вы выбрали, а также может генерировать один, если он не существовал раньше.

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

Полезные команды

вы можете использовать более простой синтаксис для make defconfig, например:

$ make ARCH=arm your_board_defconfig

посмотреть полный список доступные defconfigs с:

$ make ARCH=arm help | grep defconfig

Если вам нужно сделать обратное действие (т. е. создать аккуратный маленький defconfig от extensive .config), вы можете использовать savedefconfig правила:

$ make ARCH=arm savedefconfig

также, как 0andriy упомянули, Вы можете использовать diffconfig скрипт для просмотра изменений с одного .config другой:

$ scripts/diffconfig .config_old .config_new

Он также генерировать include/generated/autoconf.h.

этот файл заголовка включен в исходный файл C. С другой стороны,--1--> для системы Makefile.

система сборки генерирует два файла и сохраняет их согласованность.