Que fait exactement make oldconfig dans le makefile du noyau Linux ?

Il lit le .config existant fichier qui a été utilisé pour un ancien noyau et invite l'utilisateur à entrer des options dans la source actuelle du noyau qui ne se trouvent pas dans le fichier. Ceci est utile lorsque vous prenez une configuration existante et que vous la déplacez vers un nouveau noyau.

Avant d'exécuter make oldconfig , vous devez copier un fichier de configuration du noyau d'un noyau plus ancien dans le répertoire racine du nouveau noyau.

Vous pouvez trouver une copie de l'ancien fichier de configuration du noyau sur un système en cours d'exécution à /boot/config-3.11.0 . Alternativement, le code source du noyau a des configurations dans linux-3.11.0/arch/x86/configs/{i386_defconfig / x86_64_defconfig}

Si votre source de noyau est située à /usr/src/linux :

cd /usr/src/linux
cp /boot/config-3.9.6-gentoo .config
make oldconfig

Résumé

Comme mentionné par Ignacio, il met à jour votre .config pour vous après avoir mis à jour la source du noyau, par ex. avec git pull .

Il essaie de conserver vos options existantes.

Avoir un script pour cela est utile car :

de nouvelles options peuvent avoir été ajoutées ou d'anciennes supprimées
le format de configuration Kconfig du noyau a des options qui :
- s'impliquer via select
- dépendre d'un autre via depends
Ces relations d'options rendent la résolution de configuration manuelle encore plus difficile.

Modifions .config manuellement pour comprendre comment il résout les configurations

Générez d'abord une configuration par défaut avec :

make defconfig

Modifiez maintenant le .config généré fichier manuellement pour émuler une mise à jour du noyau et exécuter :

make oldconfig

pour voir ce qui se passe. Quelques conclusions :

Lignes de type :
```
# CONFIG_XXX is not set
```
ne sont pas de simples commentaires, mais indiquent en fait que le paramètre n'est pas défini.

Par exemple, si nous supprimons la ligne :
```
# CONFIG_DEBUG_INFO is not set
```
et exécutez make oldconfig , il nous demandera :
```
Compile the kernel with debug info (DEBUG_INFO) [N/y/?] (NEW)
```
Quand c'est fini, le .config le fichier sera mis à jour.

Si vous modifiez un caractère de la ligne, par ex. à # CONFIG_DEBUG_INFO , ça ne compte pas.
Lignes de type :
```
# CONFIG_XXX is not set
```
sont toujours utilisés pour la négation d'une propriété, bien que :
```
CONFIG_XXX=n
```
est aussi compris comme la négation.

Par exemple, si vous supprimez # CONFIG_DEBUG_INFO is not set et répondez :
```
Compile the kernel with debug info (DEBUG_INFO) [N/y/?] (NEW)
```
avec N , alors le fichier de sortie contient :
```
# CONFIG_DEBUG_INFO is not set
```
et non :
```
CONFIG_DEBUG_INFO=n
```
Aussi, si nous modifions manuellement la ligne en :
```
CONFIG_DEBUG_INFO=n
```
et exécutez make oldconfig , alors la ligne est modifiée en :
```
# CONFIG_DEBUG_INFO is not set
```
sans oldconfig nous demander.
Les configurations dont les dépendances ne sont pas respectées n'apparaissent pas sur le .config . Tous les autres le font.

Par exemple, définissez :
```
CONFIG_DEBUG_INFO=y
```
et exécutez make oldconfig . Il va maintenant nous demander :DEBUG_INFO_REDUCED , DEBUG_INFO_SPLIT , etc. configs.

Ces propriétés n'apparaissaient pas sur le defconfig avant.

Si nous regardons sous lib/Kconfig.debug où ils sont définis, on voit qu'ils dépendent de DEBUG_INFO :
```
config DEBUG_INFO_REDUCED
    bool "Reduce debugging information"
    depends on DEBUG_INFO
```
Alors quand DEBUG_INFO était éteint, ils ne sont pas apparus du tout.
Les configurations qui sont selected par activé, les configurations sont automatiquement définies sans demander à l'utilisateur.

Par exemple, si CONFIG_X86=y et on supprime la ligne :
```
CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
```
et exécutez make oldconfig , la ligne est recréée sans nous demander, contrairement à DEBUG_INFO .

Cela se produit parce que arch/x86/Kconfig contient :
```
config X86
    def_bool y
    [...]
    select ARCH_MIGHT_HAVE_PC_PARPORT
```
et sélectionnez force cette option à être vraie. Voir aussi :https://unix.stackexchange.com/questions/117521/select-vs-depends-in-kernel-kconfig
Les configurations dont les contraintes ne sont pas respectées sont demandées.

Par exemple, defconfig avait défini :
```
CONFIG_64BIT=y
CONFIG_RCU_FANOUT=64
```
Si nous modifions :
```
CONFIG_64BIT=n
```
et exécutez make oldconfig , il nous demandera :
```
Tree-based hierarchical RCU fanout value (RCU_FANOUT) [32] (NEW)
```
C'est parce que RCU_FANOUT est défini à init/Kconfig comme :
```
config RCU_FANOUT
    int "Tree-based hierarchical RCU fanout value"
    range 2 64 if 64BIT
    range 2 32 if !64BIT
```
Donc, sans 64BIT , la valeur maximale est 32 , mais nous avions 64 réglé sur le .config , ce qui le rendrait incohérent.

Bonus

make olddefconfig définit chaque option à leur valeur par défaut sans demander de manière interactive. Il s'exécute automatiquement sur make pour s'assurer que le .config est cohérent au cas où vous l'auriez modifié manuellement comme nous l'avons fait. Voir aussi :https://serverfault.com/questions/116299/automatically-answer-defaults-when-doing-make-oldconfig-on-a-kernel-tree

make alldefconfig est comme make olddefconfig , mais il accepte également un fragment de configuration à fusionner. Cette cible est utilisée par le merge_config.sh script :https://stackoverflow.com/a/39440863/895245

Et si vous souhaitez automatiser le .config modification, ce n'est pas trop simple :comment activer de manière non interactive des fonctionnalités dans un fichier .config du noyau Linux ?

Met à jour une ancienne configuration avec des options nouvelles/modifiées/supprimées.