Comment créer un script menuconfig pour automatiser la configuration de la construction du noyau Linux?

10

Je veux automatiser une version Linux , mais finalement arriver à un point où je dois courir ce qui semble être une étape manuelle: make menuconfig. Cela semble synchroniser les configurations entre le système d'exploitation et les configurations du noyau?

cp git-tracked-config .config
make defconfig 
make menuconfig # <- how to automate/script this?
make V=s

Fondamentalement, comment puis-je supprimer l'appel à make menuconfigun script de génération?

En passant, ceci est en réaction à une erreur de build qui semble se produire lorsque je lance sans jamais appeler make menuconfig:

make[1]: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'.  Stop.

Ce qui semble être qu'il y a une règle manquante dans un makefile peut-être parce que le makefile lui-même n'existe PAS ou que le makefile n'a pas été généré / transformé pour contenir cette règle mais c'est une question distincte.

Il pourrait y avoir un moyen plus intelligent d'aborder tout cela ensemble. Y a-t-il d'autres configurations que je ne suis pas en train de suivre mais que je devrais (par exemple oldconfig)?

bash linux-kernel make

— tarabyte
source

1

Avez-vous testé make olddefconfig?

— jimmij

non, en savoir plus à ce sujet maintenant ... c'est tellement douloureux parce que toute petite expérience prend tellement de temps.

— tarabyte

8

Le système de construction du noyau Linux fournit de nombreuses cibles de construction, la meilleure façon de le savoir est probablement de faire make help:

Configuration targets:
  config      - Update current config utilising a line-oriented program
  nconfig         - Update current config utilising a ncurses menu based program
  menuconfig      - Update current config utilising a menu based program
  xconfig     - Update current config utilising a QT based front-end
  gconfig     - Update current config utilising a GTK based front-end
  oldconfig   - Update current config utilising a provided .config as base
  localmodconfig  - Update current config disabling modules not loaded
  localyesconfig  - Update current config converting local mods to core
  silentoldconfig - Same as oldconfig, but quietly, additionally update deps
  defconfig   - New config with default from ARCH supplied defconfig
  savedefconfig   - Save current config as ./defconfig (minimal config)
  allnoconfig     - New config where all options are answered with no
  allyesconfig    - New config where all options are accepted with yes
  allmodconfig    - New config selecting modules when possible
  alldefconfig    - New config with all symbols set to default
  randconfig      - New config with random answer to all options
  listnewconfig   - List new options
  olddefconfig    - Same as silentoldconfig but sets new symbols to their default value
  kvmconfig   - Enable additional options for guest kernel support
  tinyconfig      - Configure the tiniest possible kernel

Comme le dit jimmij dans les commentaires, les parties intéressantes se trouvent dans les oldconfigcibles associées.

Personnellement, je vous recommanderais d'y aller silentoldconfig(si rien n'a changé dans le .configfichier ou olddefconfigsi vous avez mis à jour votre .configfichier avec un nouveau noyau.

— perror
source

1

randconfigm'a surpris. Vraisemblablement utilisé pour tester des builds en générant des combinaisons improbables?

— conorsch

2

Oui, c'est précisément utilisé comme un fuzzer pour le fichier de configuration. Voir cette question: lors de la compilation du noyau Linux, à quoi sert-il make randconfig? (sur le site 'Ask Ubuntu').

— perror

2

merge_config.sh fragments de configuration

$ cd linux
$ git checkout v4.9
$ make x86_64_defconfig
$ grep -E 'CONFIG_(DEBUG_INFO|GDB_SCRIPTS)[= ]' .config
# CONFIG_DEBUG_INFO is not set
$ # GDB_SCRIPTS depends on CONFIG_DEBUG_INFO in lib/Kconfig.debug.
$ cat <<EOF >.config-fragment
> CONFIG_DEBUG_INFO=y
> CONFIG_GDB_SCRIPTS=y
> EOF
$ # Order is important here. Must be first base config, then fragment.
$ ./scripts/kconfig/merge_config.sh .config .config-fragment
$ grep -E 'CONFIG_(DEBUG_INFO|GDB_SCRIPTS)[= ]' .config
CONFIG_DEBUG_INFO=y
CONFIG_GDB_SCRIPTS=y

La substitution de processus ne pas fonctionne malheureusement:

./scripts/kconfig/merge_config.sh arch/x86/configs/x86_64_defconfig \
    <( printf 'CONFIG_DEBUG_INFO=y\nCONFIG_GDB_SCRIPTS=y\n' )

à cause de: https://unix.stackexchange.com/a/164109/32558

merge_config.shest un simple frontal pour la make alldefconfigcible.

Lors de la compilation croisée, ARCHdoit être exporté lorsque vous exécutez merge_config.sh, par exemple:

export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
make defconfig
./scripts/kconfig/merge_config.sh .config .config-fragment

Le fichier de sortie fusionné peut être spécifié explicitement avec la KCONFIG_CONFIGvariable d'environnement; sinon, il écrase simplement .config:

KCONFIG_CONFIG=some/path/.config ./scripts/kconfig/merge_config.sh .config .config-fragment

Buildroot l'automatise avec BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES: /programming/1414968/how-do-i-configure-the-linux-kernel-within-buildroot

En relation: /programming/7505164/how-do-you-non-interactively-turn-on-features-in-a-linux-kernel-config-file

— Ciro Santilli 冠状病毒审查六四事件法轮功
source

0

J'ai eu ce même problème car je voulais mettre à niveau mon noyau CentOS et je devais le faire sur plusieurs machines. Supposons ici que ma nouvelle arborescence de noyau CentOS se trouve dans /linux-5.1 (je suis connecté au compte root)

cd /linux-5.1
courir make menuconfig et apporter vos modifications et les enregistrer dans.config
copier le /linux-5.1/.config fichier sur votre serveur de développement
Maintenant, pour votre prochaine machine à mettre à niveau, vous allez copier le .configfichier de votre serveur de développement vers/linux-5.1/.config sur la nouvelle machine.

J'espère que cela aide quelqu'un dans la même situation.

— Schmiddy
source