Kernel/Gentoo Kernel Configuration Guide/fr

Le but de ce document est d'introduire les concepts d'une configuration manuelle du noyau, et d'en détailler les pièges les plus courants.

Introduction
Gentoo met à la disposition des utilisateurs deux moyens d'installation, de configuration, et de mise à jour du noyau : automatique (genkernel) et manuel. Bien que la méthode automatique puisse être considérée comme plus facile pour la plupart des utilisateurs, il y a plusieurs raisons pour lesquelles un grand nombre d'utilisateurs de Gentoo choisit de configurer le noyau à la main :


 * 1) Plus grande flexibilité
 * 2) Noyau plus compact
 * 3) Temps de compilation plus court
 * 4) Expérience didactique
 * 5) Ennui sérieux
 * 6) Connaissance absolue de la configuration noyau, et/ou
 * 7) Contrôle complet

Ce guide ne parle pas de la méthode automatique (avec genkernel). Si l'utilisation de genkernel est préférée pour gérer le noyau, reportez-vous à la documentation de Genkernel pour plus de détails.

Ce guide n'a pas l'ambition de documenter la configuration manuelle de A à Z — le processus de configuration s'appuie sur un large degré de bon sens, et un niveau de connaissance technique relativement élevé du système utilisé. Au lieu de cela, il vous présente les concepts de la configuration manuelle et détaille les pièges les plus courants que les utilisateurs se doivent d'éviter.

À ce stade, l'utilisateur est supposé avoir décompressé les sources du noyau Linux sur le disque dur (de façon générale sous ), et devrait savoir comment lancer l'utilitaire de configuration ansi que comment se déplacer dans le système de menus basé sur ncurse. Si l'utilisateur n'en est pas encore là, d'autres documentations sont disponibles. Lisez les articles suivant puis revenez sur ce guide :


 * Le document Noyau/Vue d'ensemble contient des informations sur les différents noyaux disponibles dans l'arbre Portage.
 * La page Noyau/Mise à jour explique comment mettre à jour un noyau ou comment commuter vers un autre noyau.
 * La section Configuration du noyau du manuel gentoo couvre également quelques aspects de l'installation du noyau. Sélectionnez l'architecture appropriée, puis naviguez vers la section intitulée "Configurer le noyau Linux"

Les bases
Le processus général est plutôt simple : une série d'options, sous forme de menus et sous-menus, sont présentées et le support matériel et les fonctionnalités du noyau pertinentes pour le système sont sélectionnées.

Le noyau comprend une configuration par défaut, qui est présentée la première fois que  est exécuté sur un jeu de sources particulier. Les choix par défaut sont en général à large portée et raisonnables, ce qui veut dire qu'une majorité d'utilisateurs n'auront que peu de changements à faire à cette configuration de base. Quand le choix est fait de désactiver une option qui été activée dans la configuration par défaut du noyau, il est important de s'assurer qu'une bonne compréhension de ce que cette option fait exactement est obtenue, et des conséquence de sa déactivation.

Lors d'une première configuration d'un noyau Linux, tentez de rester conservateur ; ne soyez pas trop aventurier, et contentez-vous de faire aussi peu de modification aux réglages par défaut que possible. En même temps, pensez bien qu'il y a une partie de la configuration qui se doit absolument d'être adaptée au système pour que ce dernier ne démarre !

Compilé en dur ou compilé en tant que module
Majoritairement, les options de configuration sont à trois état : elles peuvent être non compilées du tout, compilées en dur dans le noyau   ou compilées sous forme de module. Les modules sont stockés en externe sur le système de fichiers, alors que les options compilées en dur sont incluses dans l'image du noyau elle-même.

Il y a une différence importante entre compilé en dur et sous forme de modules : sauf quelques exceptions, le noyau n'essaye pas de charger un module externe quand le système pourrait en avoir besoin ; ceci est laissé à l'initiative de l'utilisateur. Alors que certaines autres parties du système peuvent disposer de mécanismes de chargement à la demande, et qu'il y ait quelques mécanismes de chargement automatique de module, il est recommandé de compiler la prise en charge du matériel et les fonctionnalités du noyau directement dans le noyau. Le noyau est ainsi assuré de disposer des fonctionnalités et de la prise en charge du matériel quand il en a besoin. Cela se fait en configurant chaque fonctionnalité du kernel à. Pour que cette configuration soit cohérente, il est également nécessaire d'inclure le support des firmware directement dans le noyau. Cela se fait en configurant les options  et   dans le fichier  du noyau ou par les choix suivants :

Pour d'autres parties de la configuration, compilée en dur est une absolue nécessité. Par exemple, si la partition root comporte un système de fichiers btrfs, le système ne démarrera pas si la prise en charge de brtfs a été compilée en tant que module. Le système devrait alors regarder dans la partition root pour trouver le module btrs (vu que les modules sont stockés dans la partition root), mais il ne peut pas lire la partition root à moins d'avoir déjà chargé le support pour btrfs! Si btrfs n'a pas été compilé en dur, le processus de démarrage n'arrivera pas à trouver la partition root.

Prise en charge du matériel
Au delà de détecter le type d'architecture du système, l'utilitaire de configuration ne cherche pas à identifier quel matériel est réellement présent sur le système. Bien qu'il existe des réglages par défaut pour la prise en charge de quelques matériels, il reviendra aux utilisateurs de trouver et sélectionner les options pertinentes pour chaque configuration matérielle.

Sélectionner les options de configuration correctes nécessite une connaissance des composants à l'intérieur de, et connectés à, l'ordinateur. La plupart du temps, ces composants peuvent être identifiés sans avoir beoin de soulever le capot. Pour la plupart des composants, l'utilisateur doit identifier le jeu de circuits (chipset) utilisé par chacun d'entre-eux, plutôt que leur nom commercial. Beaucoup de cartes d'extension sont commercialisées avec une certaine marque, mais utilisent le chipset d'un autre fabricant.

Quelques utilitaires sont là pour aider les utilisateurs à déterminer quelles configurations du noyau utiliser. (du paquet ) identifiera votre matériel PCI et AGP, ce qui inclut les composants construits sur la carte mère elle-même. (du paquet ) identifiera divers périphériques raccordés aux ports USB du système.

La situation est quelque peu confuse à cause des degrés variables de normalisation dans le monde des fabricants de matériel. A moins que l'utilisateur ne s'écarte réellement des paramétrages par défaut, les disques IDE, le clavier PS/2 ou USB et la souris devraient simplement fonctionner. Une prise en charge VGA de base pour l'écran est également incluse. Néanmoins, certains périphériques tels que les les adaptateurs Ethernet sont à peine normalisés ; pour ces périphériques les utilisateurs devront identifier leur chipset et sélectionner la prise en charge matérielle appropriée pour la carte spécifique pour disposer d'un accès au réseau.

De plus, alors que certains matériels fonctionnent tout simplement avec les réglages par défaut, des options plus spécialisées peuvent être sélectionnées pour tirer le meilleur du système. Par exemple, si le support pour le chipset IDE approprié n'a pas été activé, le disque sera très lent en accès.

Fonctionnalités du noyau
En plus de la prise en charge du matériel, les utilisateurs doivent penser aux fonctionnalités logicielles qui seront requises dans le noyau. Un exemple important d'une telle fonctionnalité est la prise en charge des systèmes de fichiers : les utilisateurs doivent sélectionner la prise en charge des systèmes de fichiers utilisés sur leurs disques durs, ainsi que pour chaque système de fichiers qu'ils pourraient utiliser sur des supports amovibles (par exemple VFAT pour des disques USB flash).

Un autre exemple courant est la fonctionnalité avancé de réseau. Pour effectuer du routage ou du pare-feu, les items pertinents de la configuration doivent être inclus dans la configuration du noyau.

Prêt ?
Maintenant que les concepts ont été présentés, il devrait être facile d'identifier la matériel du système, de naviguer dans l'interface de menuconfig, et de sélectionner les options requises du noyau pour le système.

La suite de ce guide vise à éclaircir certaines zones de confusion fréquente, et à fournir des conseils sur la manière d'éviter les problèmes les plus couramment rencontrés par les utilisateurs. Bonne chance !

Les disques SATA sont SCSI
La plupart des ordinateurs de bureau modernes sont livrés avec des unités de stockage (disques durs et lecteurs de CD/DVD) sur un bus Serial ATA, plutôt que sur l'ancien bus Parallel_ATA(câble en ruban).

La prise en charge de SATA dans Linux est mise en œuvre dans une couche connue sous le nom de libata, qui siège en dessous du sous-système SCSI. Pour cette raison, les pilotes SATA sont trouvés dans la section des pilotes SCSI de la configuration. En outre, les périphériques de stockage seront traités comme des périphériques SCSI, ce qui veut dire que la prise en charge des disques/CDROM SCSI sera également requise. Le premier disque SATA sera nommé et le premier lecteur CD/DVD SATA sera nommé.

Bien que la majorité de ces pilotes soit pour les contrôleurs SATA, libata n'a pas été conçue pour être spécifique à SATA. Tous les pilotes courants IDE seront aussi portés dans libata dans un futur proche, et après cela, les considérations évoquées plus haut, s'appliqueront aussi aux utilisateurs d'IDE.

Jeux de circuits IDE et DMA
Malgré l'introduction de SATA, les périphériques IDE sont encore courants et beaucoup de systèmes en dépendent. IDE est une technologie parfaitement générique et, grâce à cela, Linux prend en charge presque tous les contrôleurs IDE directement à l'installation sans qu'aucune option spécifique au contrôleur ait besoin d'être activée.

Cependant, IDE est une technologie ancienne, et dans son implémentation originale entrées/sorties programmées, elle est incapable de procurer les débits requis pars les accès rapides aux périphériques des stockage modernes. Le pilote IDE générique est limité à ces modes de transfert PIO, qui conduisent à des débits de transfert bas, et à une utilisation significative de CPU lors du transfert de données vers/du disque.

Sauf si un utilisateur a affaire à un système pré-1995, le contrôleur IDE prend également en charge un mode de transfert alternatif, connu sous le nom de Direct Memory Access (accès direct à la mémoire - DMA). DMA est beaucoup plus rapide, et l'utilisation du CPU est à peine affectée lors des transferts de données. Si le système souffre d'une performance générale faible qlors qu'il utilise un disque IDE, il est fort probable que le mode DMA ne soit pas utilisé et doit être activé.

Si libata n'est pas utilisé pour les disques IDE, il est nécessaire de vérifier que DMA est activé. La commande suivante peut être utilisée pour déterminer si DMA est utilisé :

Pour activer DMA pour d'anciens disques IDE (qui est une fonctionnalité dépréciée), activer les options de configuration du noyau suivantes.

USB host controllers
USB is a widely adopted bus for connecting external peripherals to a computer. One of the reasons behind the success of USB is that it is a standardized protocol, however the USB host controller devices (HCDs) implemented on the host computer do vary a little. There are 4 main types:


 * 1)   is the Universal Host Controller Interface. It supports USB 1.1, and is usually found on motherboards based on a VIA or Intel chipset.
 * 2)   is the Open Host Controller Interface. It supports USB 1.1 and is usually found on motherboards based on an Nvidia or SiS chipset.
 * 3)   is the Extended Host Controller Interface. It is the only common host controller to support USB 2.0, and can typically be found on any computer that supports USB 2.0.
 * 4)   is the eXtensible Host Controller Interface. It is the host controller for USB 3.0 and is compatible with USB 1.0, 1.1, 2.0, 3.0 and future speeds. Enable this feature when the board supports USB 3.0.

Most systems come with two of the above interface types: XHCI (USB 3.0) and EHCI (USB 2.0). To use USB devices, it is no longer necessary to select both options since XHCI is compatible with slower USB-controllers. Users can also enable EHCI to be "extra" safe; it does no harm if USB 2.0 controllers are unavailable.

If the relevant options corresponding to the USB HCD types present on the system are not selected, then 'dead' USB ports may be experienced. This case can be determined if a working USB device is plugged in, but it does not get power or respond in any way.

A neat trick (from the  package) makes it relatively easy to detect which HCDs are present on system. Ignoring the SATA controller which was also matched, it is easy to spot that this system requires EHCI and XHCI support:

Select the HCDs present on the system. In general select all three options for maximum support, or if the correct option is uncertain:

In Linux kernel 3.12.13 and later,   has to be enabled if the USB controller is OHCI and a USB keyboard or mouse is used.

Multiprocessor, Hyper-Threading and multi-core systems
Many computer systems are based on multiple processors, but not always in an immediately obvious way.


 * Many of Intel's CPUs support a technology which they call hyper-threading. This technology enables a single CPU to be viewed by the system as two logical processors.
 * Most Intel/AMD CPUs actually consist of multiple physical processors inside a single package, these processors are known as multi-core processors.
 * Some high-end computer systems actually have multiple physical processors installed on specialized motherboards to provide a significant performance increase over a uniprocessor system. System users will probably know if they have such a system, since they are not cheap.

In all of these cases, the appropriate kernel options must be selected to obtain optimum performance from these setups:

The next option not only enables power management features, but might also be a requirement for making all CPUs available to the system:

Prise en charge de la mémoire x86 haute
Due to limitations in the 32-bit address space of the architecture, a kernel with default configuration can only support up to 896MB RAM. If a system has more memory, only the first 896MB will be visible, unless high memory support has been enabled.

La prise en charge de la mémoire haute n'est pas activée par défaut, parce qu'elle introduit une légère surcharge. Ne vous laissez pas distraire par cela, la surcharge est insignifiante comparée au gain de performance procuré par une augmentation de la taille de la mémoire !

Choose the 4GB option, unless your system has more than 4GB of RAM:

Compressed kernel modules
From kernel version 3.18.x (and up) compression of kernel modules has been possible. gzip and xz compression are available. It is important to emerge with the proper USE flags before compiling a kernel with compressed modules:

Re-emerge :

Enable module compression and select a preferred compression method:

Usually runs. If did not have the proper USE flags set (see the  step above) the first time it was run, then the dependency list will be empty. The system will therefore be unable to load any modules that were built compressed.

After kmod has been recompiled, re-run as a solution to this problem:

Introduction
When reading about kernel configuration, often times settings are described as CONFIG_. This short-hand notation is what the kernel configuration actually uses internally, and is what will be found in the kernel configuration file (be it or in the auto-generated  file). Of course, using short-hand notation would not do much good if this cannot translate this to the real location in the kernel configuration. The tool makes this possible.

Traduire CONFIG_FOO en un emplacement réel dans les menus de configuration
Suppose the CONFIG_TMPFS_XATTR feature needs to be enabled. Launch the kernel configuration menu and press the  key. This will open a search box. In the search box, type CONFIG_TMPFS_XATTR.

The following is an output of the result of this search:

Cette sortie nous fournit une multitude d'informations intéressantes.

With this information, it should be possible to translate any CONFIG_* requirements fairly easily. In short, it means a user must


 * 1) Enable the settings described in the Depends on field;
 * 2) Navigate where Location: points;
 * 3) Toggle the value referred to by Prompt:;

Autres documentations sur la configuration du noyau
So far only general concepts and specific problems related to kernel configuration has been discussed; precise details have been left up to the user to discover. However, other parts of the Gentoo documentation collection provide specialized details for the topics at hand.

Such documents may be helpful while configuring specific areas of the kernel. Although this warning was mentioned previously in this guide, remember: users who are new to kernel configuration should not be adventurous when attempting to configure their kernels. Start by getting a basic system up and running, support for your audio, printing, etc., can always be added at a later date.

Getting the basics of a kernel operational will help users in later configuration steps because the user will know what is breaking their system and what is not. It is always wise to save the base (working) kernel configuration in a folder other than the kernel's sources folder before attempting to add new features or hardware.


 * The ALSA article details the configuration options required for sound card support. Note that ALSA is an exception to the suggested scheme of not building things as modules: ALSA is actually much easier to configure when the components are modular.


 * The Bluetooth article details the options needed in order to use Bluetooth devices.


 * The IPv6 router guide describes how to configure the kernel for routing using the next generation network addressing scheme.


 * If the closed-source nVidia graphics drivers will be used for improved 3D graphics performance, the nVidia Guide lists the options that should and should not be selected on such a system.


 * Amongst other things, the Power Management guide explains how to configure the kernel for CPU frequency scaling, and for suspend and hibernate functionality.


 * If running a PowerPC system, the PPC FAQ has a few sections about PPC kernel configuration.


 * The Printing guide lists the kernel options needed to support printing in Linux.


 * The USB Guide details the configuration settings required to use common USB devices such as keyboards, mice, storage devices, and USB printers.

Les changements apportés à la configuration restent sans effet
It is very common for users to make a configuration change, but then make a small mistake in the process of actually booting to their newly configured kernel. They reboot into a kernel image that is not the one they just reconfigured, observe that whatever problem they were trying to solve is still present, and conclude that the configuration change does not solve the problem.

The process of compiling and installing kernels is outside the scope of this document; refer to the Kernel Upgrade Guide for general guidance. In short, the process to get a modified kernel is the following: 1) configure, 2) compile, 3) mount (if not already mounted), 4) copy new kernel image to, 5) Make sure the bootloader will reference the new kernel, 6) reboot. If one of those final stages has been missed, then the changes will not properly take effect.

It is possible to verify if the kernel that has booted matches the newly kernel compiled on the hard disk. This is performed by examining the date and time of the kernel's compilation. Assuming the system architecture is and the kernel sources are installed at, the following command can be used:

The above command will display the date and time the currently booted kernel was compiled.

The above command displays the date and time that the kernel image on the hard disk was last compiled.

If the time stamps from the above commands differ by more than 2 minutes, it indicates a mistake was made during kernel reinstallation and the system has not booted from the newly modified kernel image.

Les modules ne sont pas chargés automatiquement
As mentioned earlier in this document, the kernel configuration system hides a large behavioral change when selecting a kernel component as a module (M) rather than built-in (Y). It is worth repeating this again because so many users fall into this trap.

When selecting a component as built-in, the code is built into the kernel image (bzImage). When the kernel needs to use that component, it can initialize and load it automatically, without any user intervention.

When selecting a component as a module, the code is built into a kernel module file and installed on the filesystem. In general, when the kernel needs to use that component, it will not be able to find it. With some exceptions, the kernel makes no effort to actually load these modules — this task is left up to the user.

If building support for a network card as a module, and it is discovered the network is not accessible, it is probably because the module is not loaded — either this must be done manually or the system must be configured to autoload the module at boot time.

Unless a user has a reasons to do otherwise, some time can be saved by building these components directly into the kernel image, so that the kernel can automatically configure these small settings by itself.