In the first part of this series, we saw what the Linux kernel is, and in the second chapter we saw the various ways of obtaining the source code and the other pieces we need to compile it. Now that we have all the bits and required pieces, in this third part we are about ready for the main course: configuring, compiling and installing the kernel. In this part, I will be using specifically the version of the kernel source code from the Ubuntu repositories. There will be few differences if the reader should choose to use the version downloaded directly from the Kernel.org project. One reason to do so would be to work on the most recent kernel version – or even, if we are feeling really adventurous, on a release candidate for the next version.

Dans la première partie de cette série, nous avons vu ce qu'est le noyau Linux, et dans le deuxième chapitre, nous avons vu les différentes façons d'obtenir le code source et les autres morceaux dont nous avons besoin pour le compiler. Maintenant que nous avons tous les bouts et pièces nécessaires, dans cette troisième partie, nous sommes enfin prêts pour le plat principal : la configuration, la compilation et l'installation du noyau.

Dans cette partie, je vais utiliser précisément la version du code source du noyau qui est dans les dépôts Ubuntu. Il y aura quelques différences si le lecteur choisit d'utiliser la version téléchargée directement du projet Kernel.org. Une des raisons de le faire serait de travailler sur la version la plus récente du noyau - ou même, si on se sent vraiment aventureux, sur une « release candidate » pour la prochaine version.

THE KERNEL CONFIGURATION SYSTEM If we take a look at the source code directories and the files contained within, we can find a series of files whose purpose we can quickly understand. Files with extension .c are clearly source code files in the C programming language, and those with extension .h are header files for the same code. In part 2 of this series, we also learned that the Makefile we find in each directory and subdirectory is a file that gives the compiler instructions on how to compile the source code: which source files to compile, how the output files are to be named, and what compiler parameters are to be appended. When we peruse each Makefile, we can see that the file in each directory refers only to the source code placed in that directory. This means there is a separation between the different parts of the kernel source tree: each directory or subdirectory may be compiled independently. When we come to the concept of kernel modules, we will see this means we will be able to compile just a single module at a time, without having to compile the entire kernel if it is not necessary.

LE SYSTÈME DE CONFIGURATION DU NOYAU

Si nous jetons un coup d’œil aux répertoires du code source et aux fichiers qu'ils contiennent, nous trouverons une série de fichiers dont nous pouvons comprendre rapidement le but. Les fichiers avec l'extension .c sont clairement des fichiers de code source dans le langage de programmation C, et ceux avec l'extension .h sont des en-tête de fichiers pour le même code. Dans la partie 2 de cette série, nous avons également appris que le Makefile que nous trouvons dans chaque répertoire et sous-répertoire est un fichier qui donne au compilateur des instructions sur la façon de compiler le code source : quels fichiers sources compiler, comment nommer les fichiers de sortie et quels paramètres du compilateur utiliser.

Lorsque nous parcourons chaque Makefile, nous pouvons voir que le fichier dans chaque répertoire se réfère uniquement au code source placé dans ce répertoire. Cela signifie qu'il y a une séparation entre les différentes parties de l'arborescence des sources du noyau : chaque répertoire ou sous-répertoire peut être compilé indépendamment. Quand nous arriverons à la notion de modules du noyau, nous verrons que cela signifie que nous pourrons compiler un seul module à la fois, sans avoir à compiler le noyau entier si ce n'est pas nécessaire.

But what about the Kconfig files we can also find in each directory? The Kconfig files are instruction files targeted at the kernel configuration system. The Linux kernel is a very large piece of code. In fact, it hit 15 million lines of code back in 2011 (see http://arstechnica.com/business/2012/04/linux-kernel-in-2011-15-million-total-lines-of-code-and-microsoft-is-a-top-contributor/) and 17 million lines in June 2013 version 3.10 (http://www.extremetech.com/computing/175919-who-actually-develops-linux-the-answer-might-surprise-you). These two references are quite interesting, by the way, since both address the question of who contributes to the kernel source code. With such a behemoth to compile, we will need some sort of automated configuration system. This is where the Kconfig files come in, giving instructions on which options are available in each directory, and helping create a giant kernel configuration script.

Mais quid des fichiers KConfig que nous pouvons également trouver dans chaque répertoire ?

Ces fichiers sont des fichiers d'instructions ciblés sur le système de configuration du noyau. Le noyau Linux contient vraiment beaucoup de code. En fait, cela représentait 15 millions de lignes de code en 2011 (voir http://arstechnica.com/business/2012/04/linux-kernel-in-2011-15-million-total-lines-of-code-and-microsoft-is-a-top-contributor/) et 17 millions de lignes en juin 2013 pour la version 3.10 (http://www.extremetech.com/computing/175919-who-actually-develops-linux-the-answer-might-surprise-you). Par ailleurs, ces deux références sont très intéressantes puisque les deux traitent de la question de savoir qui contribue au code source du noyau.

Avec un tel mastodonte à compiler, nous aurons besoin d'une sorte de système de configuration automatique. C'est là que les fichiers KConfig interviennent, en donnant des instructions sur les options qui sont disponibles dans chaque répertoire, pour aider à créer un script géant pour la configuration du noyau.

For example, in source directory security/selinux, the Kconfig file contains the stanza: config SECURITY_SELINUX_BOOTPARAM bool “NSA SELinux boot parameter” depends on SECURITY_SELINUX default n help This option adds a kernel parameter 'selinux', which allows SELinux to be disabled at boot. If this option is selected, SELinux functionality can be disabled with selinux=0 on the kernel command line. The purpose of this option is to allow a single kernel image to be distributed with SELinux built in, but not necessarily enabled. If you are unsure how to answer this question, answer N.

Par exemple, dans le répertoire source security/selinux, le fichier Kconfig contient le paragraphe :

config SECURITY_SELINUX_BOOTPARAM

      
bool "NSA SELinux boot parameter" 
depends on SECURITY_SELINUX
default n 
help 
  
  Cette option ajoute un paramètre de noyau « 'selinux' », qui permet de désactiver SELinux au démarrage. Si cette option est sélectionnée, la fonctionnalité SELinux peut être désactivée avec selinux=0 sur la ligne de commande du noyau. Le but de cette option est de permettre de distribuer une seule image du noyau avec SELinux intégré, mais pas nécessairement activé. 

Si vous ne savez pas comment répondre à cette question, répondez N.

This should be largely self-explanatory. The stanza indicates the configuration script that the user must be shown a boolean (true/false) checkbox, through which the new kernel can be configured to accept or not the “selinux” boot parameter that allows the Security Enhanced Linux kernel module (SELinux) to be deactivated at boot. Naturally, this is not a very good idea on a production system, which is why the default option is “n” - for “no”. In file net/ipv6/Kconfig, we find a more complex example: config INET6_TUNNEL tristate default n config IPV6_TUNNEL tristate “IPv6: IP-in-IPv6 tunnel (RFC2473)” select INET6_TUNNEL —help— Support for IPv6-in-IPv6 and IPv4-in-IPv6 tunnels described in RFC 2473. If unsure, say N.

Ceci devrait être globalement explicite. Le paragraphe indique au script de configuration qu'il doit afficher à l'utilisateur une case booléenne (vrai/faux), grâce à laquelle le nouveau noyau peut être configuré pour accepter ou non le paramètre de démarrage « selinux » qui permet de désactiver au démarrage le module de sécurité renforcée (« Security Enhanced Linux », ou SELinux). Naturellement, ce n'est pas une très bonne idée sur un système de production et c'est pourquoi l'option par défaut est « n » - pour « non ».

Dans le fichier net/ipv6/Kconfig, nous trouvons un exemple plus complexe :

config INET6_TUNNEL

      tristate 
      default n 

config IPV6_TUNNEL

 tristate "IPv6: IP-in-IPv6 tunnel (RFC2473)" 
 select INET6_TUNNEL 
 ---help--- 
     Support pour les tunnels IPv6-in-IPv6 and IPv4-in-IPv6 décrits dans la
     RFC 2473. 
     Dans le doute, choisissez N.

The first stanza concerns the module that allows the kernel to create tunnels through IPv6 address space. The user will, in this case, be shown a tristate option box, that will give several options: • “Y” to compile the module directly into the kernel. It will be included in the vmlinuz file and loaded at system boot, whether used or not. • “N” to exclude the module from the new kernel. • “M” to compile the module as a loadable file, that will not be loaded into RAM at boot, but only if required during system operation. The second stanza depends on the presence of the above: if present, the user may configure support for RFC2473 tunnels in either modular or built-in forms. Now, we need to access the configuration script itself. However, before doing so, it is usually recommended to begin by clearing up any leftover configuration. To do so, issue: $ make mrproper

Le premier paragraphe concerne le module qui permet au noyau de créer des tunnels à travers l'espace d'adressage IPv6. L'utilisateur, dans ce cas, verra une boîte d'option à trois états, qui donnera plusieurs options : • « Y » pour compiler le module directement dans le noyau. Il sera inclus dans le fichier vmlinuz et chargé au démarrage du système, qu'il soit utilisé ou non. • « N » pour exclure le module du nouveau noyau. • « M » pour compiler le module comme un fichier chargeable, qui ne sera pas chargé dans la RAM au démarrage, mais seulement si c'est nécessaire pendant le fonctionnement du système.

Le deuxième paragraphe dépend de la présence de ce qui précède : s'il est présent, l'utilisateur peut configurer le support pour les tunnels RFC2473 soit sous forme de module, soit intégré.

Maintenant, nous avons besoin d'accéder au script de configuration lui-même. Cependant, avant de le faire, il est habituellement recommandé de commencer par nettoyer toute configuration restante. Pour ce faire, lancez :

$ make mrproper

As discussed in part 2, we have at least four different configuration scripts we can use. Two are based on text environments: “make config” and “make menuconfig”. Two more are based on graphical toolkits: “make xconfig” on the Qt toolkit, and “make gconfig” on the Gtk libraries. Take your choice – as a last resort, all of these scripts rely on the same Kconfig files. In my case, I will be using $ make menuconfig largely because I am comfortable with this lightweight environment that I have been using since way back when (Slackware days, to be precise). This is what you should see something like the image shown below.

Comme indiqué dans la partie 2, nous avons à notre disposition au moins quatre scripts de configuration différents. Deux sont basés sur des environnements textuels : « make config » et « make menuconfig ». Deux autres sont graphiques : « make xconfig » basé sur la boîte à outils Qt et « make gconfig » basé sur les bibliothèques Gtk. Faites votre choix - au bout du compte, tous ces scripts s'appuient sur les mêmes fichiers Kconfig. Dans mon cas, j'utiliserai :

$ make menuconfig

principalement parce que je suis à l'aise avec cet environnement léger que j'utilise depuis de nombreuses années (ma période Slackware, pour être précis). Vous devriez voir quelque chose ressemblant à l'image ci-dessous.

CONFIGURING THE KERNEL Options within brackets are the boolean choice widget that allow us to activate “[*]” or deactivate “[ ]” a feature. Some choices may be forced upon us by other options we have taken previously, in which case the widget will appear as “-*-”. Options within keys correspond to the tristate widget, that allow us to activate a feature directly within the kernel “<*>”, as a loadable module “<M>” or deactivate the feature “< >”. In this latter case, the feature will not be available at all to the new kernel. Options with the “—>” tail on their description indicate a sub-menu that can be accessed with the ENTER key. Most navigation keys are indicated on-screen, the only prominent exception being the SPACE key that is quite useful to switch between option values. Most available options will not be immediately of use when compiling our first kernel. I would suggest the reader leave the default options on, they are fine for typical use patterns. Instead, I would like to point out several specific features that may be more of interest.

CONFIGURER LE NOYAU

Les options entre crochets sont des choix booléens, qui nous permettent d'activer « [*] » ou désactiver « [ ] » une fonctionnalité. Certains choix peuvent nous être imposés par d'autres options que nous avons sélectionnées antérieurement et, dans ce cas, le widget apparaîtra comme « -*- ». Les options qui ont trois choix possibles apparaissent ainsi, et nous permettent d'activer une fonction directement dans le noyau « <*> », comme un module chargeable « <M> » ou désactiver la fonction « < > ». Dans ce dernier cas, la fonction ne sera pas disponible du tout sur le nouveau noyau.

Des options dont la description se termine par « —> » indiquent un sous-menu auquel vous pouvez accéder avec la touche ENTRÉE. La plupart des touches de navigation sont indiquées à l'écran, la seule exception importante étant la BARRE D'ESPACE qui est très utile pour basculer entre les différentes options.

La plupart des options disponibles ne seront pas forcément utiles lors de la compilation de notre premier noyau. Je conseillerais au lecteur de laisser les options par défaut, elles conviennent pour les modes d'utilisation typiques. À la place, je voudrais souligner plusieurs caractéristiques spécifiques qui peuvent être plus intéressantes.

The first place I would stop at is the very first option presented in the menu, “64-bit kernel”. It does seem likely that one could compile a 64-bit kernel on a 64-bit platform (computer and operating system), since the appropriate C library functions will be available, and likewise for compiling a 32-bit kernel on a 32-bit system. However, it should also be possible in theory to go a little further in the Linux world, as for UNIX from which it is derived. In these systems, it should be quite possible to perform what is called “cross-compiling”, in which a program destined for one platform is compiled upon another. This holds both for compiling a 64-bit kernel on a 32-bit machine, and the opposite. Unfortunately, in practical terms my experience with the Ubuntu 14.04 distribution and kernel source code version 3.13.11.2 leads me to say that things are broken and cross-compiled kernels will actually compile, but will not run on the target computer (the new kernel will not find the init program, even with the appropriate “init=” kernel parameter). So the takeaway for the time being is indeed that we need to compile a 32-bit kernel on a 32-bit operating system, and a 64-bit kernel on a 64-bit computer.

La première sur laquelle je voudrais m'arrêter est la première option présentée dans le menu, « noyau 64-bit ». Il semblerait logique qu'on puisse compiler un noyau 64-bit sur une plateforme 64-bit (ordinateur et système d'exploitation), puisque les fonctions de la bibliothèque C appropriées seront disponibles, et de même pour la compilation d'un noyau 32-bit sur un système 32-bit. Cependant, il devrait également être possible en théorie d'aller un peu plus loin dans le monde Linux, comme pour UNIX dont il est dérivé. Dans ces systèmes, il doit être tout à fait possible d'effectuer ce qu'on appelle la « compilation croisée », qui permet de compiler un programme destiné à une plateforme sur une autre plateforme. Cela vaut aussi bien pour compiler un noyau 64-bit sur une machine 32-bit, que l'inverse. Malheureusement, dans la pratique mon expérience avec Ubuntu 14,04 et la version 3.13.11.2 des sources du noyau m'amène à dire que cela ne fonctionne pas : la compilation croisée en elle-même fonctionne, mais les noyaux obtenus ne s'exécuteront pas sur l'ordinateur cible (le nouveau noyau ne trouvera pas le programme init, même avec le paramètre « init= » approprié). Ainsi, pour le moment, nous devons vraiment compiler un noyau 32-bit sur un système d'exploitation 32-bit, et un noyau 64-bit sur un ordinateur 64-bit.

At the second option, “General setup”, we have access to several very basic choices for our new kernel. We shall leave most of these alone, except for “Default hostname” and “Arbitrary version signature”. These two options are the ones that stamp each kernel with the information that can be retrieved in the /proc virtual file system. Try this out on your computer, it can do no harm: $ cat /proc/version_signature Ubuntu 3.13.0-24.47-generic 3.13.9 In my case, no hostname is indicated on which the kernel has been compiled, so whoever compiled kernel 3.13.0-24 for Linux Mint left the Default hostname option at its default “(none)” value. On the other hand, the “Ubuntu 3.13.0-24.47-generic 3.13.9” character string is what they had in the “Arbitrary version” option.

À la deuxième option, « Configuration générale », nous avons plusieurs choix très basiques pour notre nouveau noyau. Nous n'allons pas y toucher pour la plupart, sauf « nom d'hôte par défaut » et « signature de version arbitraire ». Ces deux options sont celles qui estampillent chaque noyau avec les informations qui peuvent être récupérées dans le système de fichiers virtuel /proc. Essayez ceci sur votre ordinateur, cela ne peut pas faire de mal :

$ cat /proc/version_signature Ubuntu 3.13.0-24.47-generic 3.13.9

Dans mon cas, le nom d'hôte sur lequel le noyau a été compilé n'est pas indiqué, car celui qui a compilé le noyau 3.13.0-24 pour Linux Mint a laissé l'option de nom d'hôte par défaut à sa valeur par défaut « aucun ». Par ailleurs, la chaîne de caractères « Ubuntu 3.13.0-24.47-generic 3.13.9 » est ce qu'il y avait dans l'option « version arbitraire ».

I have changed these in the screen capture (below), since it is always a Good Idea ™ to give your kernels an identifying string. This can help understand later on what particular purpose you were compiling a particular kernel for. A version number can also come in useful when a series of kernels are compiled to try to solve a particular problem: they can be used to note and keep track of progress. Let us go back up to the initial menu level, and enter the “Processor type and options” configuration setting. This is where the heavy lifting starts, and we can fine-tune our new kernel to the hardware we wish to run it on. This section also gives us a feeling for the extreme range of different physical architectures the Linux kernel handles: specific microcode for Intel and AMD range processors, software options such as Linux as a guest virtual machine operating system within Linux itself, etc.

J'ai changé ces options dans la capture d'écran (ci-dessous), puisque c'est toujours une Bonne Idée ™ de donner à vos noyaux une chaîne d'identification. Cela peut aider à comprendre plus tard dans quel but précis vous avez compilé un noyau précis. Un numéro de version peut également vous servir lorsqu'une série de noyaux est compilée pour tenter de résoudre un problème particulier : ils peuvent être utilisés pour noter et suivre les progrès.

Revenons au niveau de menu initial et entrons dans la configuration du « Type de processeur et options ». C'est là que le gros du travail commence et que nous pouvons affiner notre nouveau noyau pour le matériel sur lequel nous voulons l'exécuter. Cette section nous donne aussi une idée de l'extrême variété des différentes architectures physiques que gère le noyau Linux : microcode spécifique pour processeurs Intel et AMD, options logicielles telles que Linux en tant que système d'exploitation d'une machine virtuelle invitée au sein de Linux lui-même, etc.

If we stop a minute at the “Symmetric multi-processing support” option, this is where we can deactivate multi-processor support within the kernel. Some of us still remember when multi-processor support was a (paid) extra on a Windows system, even the server variants. In any case, it is standard in the Linux kernel since the 2.0 version series. Though it can be deactivated, this really makes little sense at this point in time. Most current processors contain multiple cores, or at the very least HyperThreading which makes a single core appear to the operating system to contain various logical cores (usually two per physical core). SMP is the subsystem that handles all this. On the other hand, when compiling a kernel for a very limited processor on a machine with very little RAM, it is possible to remove this part of the kernel and release a few tens of kBytes of RAM that otherwise would be occupied. Going down to the “Processor family” sub-menu, we are given the choice of a specific family of processors to compile for. If we have chosen to compile a 64-bit kernel, the choice is between the original Opteron/Athlon family, the older and newer Intel Xeon families, the 64-bit Intel Atom, and finally a default “Generic-x64-64” option. This latter is the most conservative choice, and possibly the best if our new kernel may eventually get executed on more than one computer.

Si nous nous arrêtons une minute sur l'option « Support du multi-traitement symétrique », c'est là que nous pouvons désactiver le support multi-processeur à l'intérieur du noyau. Certains d'entre nous se souviennent du temps où le support multi-processeur était un ajout (payant) sur un système Windows, même les variantes pour serveurs. En tout cas, c'est intégré par défaut dans le noyau Linux depuis la version 2.0. Même si elle peut être désactivée, cela présente vraiment peu d'intérêt de nos jours. La plupart des processeurs actuels contiennent plusieurs cœurs, ou au moins de l'HyperThreading qui fait qu'un seul noyau apparaît au système d'exploitation comme s'il contenait différents cœurs logiques (généralement deux par cœur physique). SMP est le sous-système qui gère tout cela. En revanche, lorsqu'on compile un noyau pour un processeur très limité sur une machine avec très peu de RAM, il est possible d'enlever cette partie du noyau et de libérer quelques dizaines de Ko de RAM qui autrement seraient occupés.

En descendant dans le sous-menu « Famille du processeur », on peut choisir de compiler pour une famille spécifique de processeurs. Si nous avons choisi de compiler un noyau 64-bit, nous aurons le choix entre la famille d'origine Opteron/Athlon, les familles anciennes ou nouvelles d'Intel Xeon, l'Intel Atom 64-bit, et enfin une option par défaut « Generic-x64-64 ». Ce dernier est le choix le plus conservateur, et peut-être le meilleur si notre nouveau noyau risque d'être exécuté sur plusieurs ordinateurs.

If we have chosen to compile a 32-bit kernel, the range of options is rather more vast, reflecting the evolution of the IA-32 processors over the years. The very early i386 has now been removed, and choices start at the i486, going on up through the various generations of 32-bit Pentium I, II, III and IV processors, several variants by AMD and other brands, ending up with the Intel Core 2 and 32-bit Intel Atom. As a general policy, it is perhaps best to aim lower rather than higher, since more recent processors will usually have backward-compatibility with older offerings. Nowadays, compiling a kernel with the “Pentium-III/Celeron/Pentium-III Xeon” is probably a reasonable choice for most use cases (below left). As mentioned in the first part of this series, there has been some talk about the recent move by some distributions to include the Physical Address Extension (PAE) feature by default in default kernels. Some versions of the Pentium III had this deactivated within the hardware, so a kernel that has PAE activated cannot work on these processors. In order to compile a kernel with PAE deactivated, in the first place it must be a 32-bit kernel: 64-bit versions always contain a mechanism similar to PAE since these processors are built to handle more than 4GBytes of memory – this is one of the advantages of using numbers with more bits in your architecture.

Si nous avons choisi de compiler un noyau 32-bit, l'éventail des options est un peu plus grand, reflétant l'évolution des processeurs IA-32 au cours des années. Le i386 d'origine a maintenant été supprimé et les choix démarrent au i486, passent par les différentes générations de processeurs 32-bit Pentium I, II, III et IV, plusieurs variantes par AMD et d'autres marques, pour finir avec l'Intel Core 2 et l'Intel Atom 32-bit. En règle générale, il est souvent préférable de viser trop bas plutôt que trop haut, car les processeurs les plus récents ont généralement une compatibilité descendante avec des offres plus anciennes. De nos jours, la compilation d'un noyau avec « Pentium III/Celeron/Pentium III Xeon » est probablement un choix raisonnable pour la plupart des cas d'utilisation (ci-dessous à gauche).

Comme mentionné dans la première partie de cette série, il a été question du changement récent de certaines distributions pour inclure la fonctionnalité « Physical Address Extension » (PAE) par défaut dans les noyaux. Certaines versions du Pentium III avaient cette option désactivée dans le matériel, donc un noyau avec PAE activé ne peut pas fonctionner sur ces processeurs. Pour compiler un noyau avec PAE désactivé, en premier lieu, il doit s'agir d'un noyau 32-bit : les versions 64-bit contiennent toujours un mécanisme similaire à PAE puisque ces processeurs sont conçus pour gérer plus de 4 Go de mémoire - c'est l'un des avantages d'utiliser des nombres avec plus de « bit » dans votre architecture.

When you have chosen the 32-bit kernel option, navigate to “Processor type and features”, and towards the last third of the list there is an option called “High Memory Support” (shown below right). This needs to be activated in order to access the full contents of a 4 GByte RAM memory, or to go further up to 64 GBytes. If the 64 GByte option is on, the PAE option will be inserted into the menu a bit lower down. If the High Memory Support is either off (use up to 3 GBytes of RAM) or at the 4 GByte choice, PAE should be automatically deactivated. Finally, if you wish to examine and/or configure the additional drivers contributed by Canonical to the kernel source, navigate back to the main menu and you will find a separate “Ubuntu Supplied Third Party Drivers” sub-menu (shown below) that contains some of their input. Naturally, this is included only with the version of the kernel code from the Ubuntu repositories. When you are satisfied with your choices, exit the configuration menu, saving the configuration in the default file .config .

Lorsque vous avez choisi l'option du noyau 32-bit, allez dans « Type de processeur et fonctionnalités » et, vers le dernier tiers de la liste, il y a une option appelée « Support de la Mémoire Haute » (ci-dessous à droite). Celle-ci doit être activée afin d'accéder à l'intégralité du contenu d'une mémoire RAM de 4 Go, ou pour aller jusqu'à 64 Go. Si l'option de 64 Go est activée, l'option PAE sera insérée dans le menu un peu plus bas. Si le support de la mémoire haute est désactivé (utiliser jusqu'à 3 Go de RAM) ou sur le choix de 4 Go, PAE devrait être désactivé automatiquement.

Enfin, si vous souhaitez examiner et/ou configurer les pilotes supplémentaires apportés par Canonical aux sources du noyau, retournez au menu principal et vous trouverez un sous-menu séparé « pilotes tiers fournis par Ubuntu » (illustré ci-dessous) qui en contient une partie. Naturellement, ceci est inclus uniquement avec la version du code du noyau des dépôts Ubuntu.

Lorsque vous êtes satisfait de vos choix, quittez le menu de configuration, en sauvegardant la configuration dans le fichier par défaut .config.

COMPILING THE NEW KERNEL Compiling the kernel has two different stages: compiling the kernel itself, and compiling the loadable modules – though this second part is performed only if the option for modules has been activated, as it usually is. To start this quite lengthy process, issue the command: $ make and the default Makefile target of compiling the kernel will be executed. Initially, this command compiled only the kernel proper, however in recent versions of the kernel source both the kernel and its modules are compiled and updated.

COMPILER LE NOUVEAU NOYAU

La compilation du noyau comporte deux étapes différentes : compiler le noyau lui-même, et compiler les modules chargeables - bien que cette seconde partie ne soit effectuée que si l'option pour les modules a été activée, ce qui est généralement le cas.

Pour commencer ce très long processus, exécutez la commande :

$ make

et la cible par défaut du Makefile, à savoir la compilation du noyau, sera exécutée. Initialement, cette commande compilait seulement le noyau proprement dit, mais dans les versions récentes des sources du noyau, à la fois le noyau et ses modules sont compilés et mis à jour.

Be prepared for the processor to work quite hard and for an extended period of time. It is important to make sure ventilation is adequate since the computer will tend to heat up (this is best done on a desktop machine, if at all possible), and will consume power liberally – so plug it in if running off the battery! On a dual-core Intel Core i5, the complete compilation process took about two hours: real 126m0.103s user 117m35.622s sys 13m31.106s If we make a change in the kernel configuration, such as changing the Arbitrary version character string as above, executing a new compilation process will need to compile only those parts that have changed. If our alteration affects only the kernel proper, all modules will need to be checked, but not compiled. Many subsystems of the kernel itself will not need to be recompiled – whole directories of the source code will be left unchanged. Compilation time will be significantly reduced, for example: real 5m51.928s user 2m19.265s sys 0m27.180s

Soyez prêt à voir le processeur travailler très dur et pendant une période de temps prolongée. Il est important de s'assurer que la ventilation est adéquate car l'ordinateur aura tendance à chauffer (c'est mieux de faire ceci sur une machine de bureau, si possible), et consommera beaucoup d'énergie - branchez-le en cas d'exécution sur la batterie ! Sur un dual-core Intel Core i5, le processus de compilation complète a pris environ deux heures :

réel 126m0.103s utilisateur 117m35.622s système 13m31.106s   Si nous faisons un changement dans la configuration du noyau, comme par exemple modifier la chaîne de version arbitraire comme ci-dessus, l'exécution d'un nouveau processus de compilation devra compiler uniquement les parties qui ont changé. Si notre modification n'affecte que le noyau lui-même, tous les modules devront être vérifiés, mais pas compilés. De nombreux sous-systèmes du noyau lui-même n'auront pas besoin d'être recompilés, des répertoires entiers du code source seront laissés inchangés. Le temps de compilation sera considérablement réduit, par exemple :

réel 5m51.928s utilisateur 2m19.265s système 0m27.180s

On the other hand, if a modification has been made in one of the modules, we can specify that just the modules need to be checked for alterations and compiled if needed, and not the kernel itself. This is managed with command: $ make modules and can considerably shorten compilation time, depending on the number of modules changed and the importance of these changes. For example, on my system: real 2m42.214s user 1m29.390s sys 0m16.867s

En revanche, si une modification a été apportée dans l'un des modules, nous pouvons préciser que seuls les modules doivent être vérifiés pour les modifications et compilés si nécessaire, pas le noyau lui-même. Ceci est géré avec la commande :

$ make modules

et peut considérablement réduire le temps de compilation, en fonction du nombre de modules modifiés et de l'importance de ces changements. Par exemple, sur mon système :

réel 2m42.214s utilisateur 1m29.390s système 0m16.867s

INSTALLING THE KERNEL Once the kernel and modules have been compiled, they can be found in the very same sub-directories as the source files. For example, in the mm (memory management) subdirectory, you will find both memory pool routines source in mm/mempool.c, and the compiled object file mm/mempool.o . Once each source file has been compiled into an object, they must be linked together into an executable file for the kernel, and transformed into loadable module files for each module. The kernel itself is file vmlinux in the tree root, and should weigh in at about 158 MBytes. This file will need to be compressed and placed in directory /boot. Once compressed using gzip, bzip or LZMA, the kernel size can go down to the 5-6 MBytes that can be expected of Linux kernel files.

INSTALLER LE NOYAU

Une fois que le noyau et les modules ont été compilés, on peut les trouver dans les mêmes sous-répertoires que les fichiers source. Par exemple, dans le sous-répertoire mm (gestion de la mémoire), vous trouverez à la fois les sources des routines de gestion de mémoire dans mm/mempool.c, et le fichier objet compilé mm/mempool.o.

Une fois que chaque fichier source a été compilé en un objet, ils doivent être reliés entre eux dans un fichier exécutable pour le noyau et transformés en fichiers de module chargeables pour chaque module. Le noyau lui-même est un fichier vmlinux dans la racine de l'arborescence et devrait peser environ 158 Mo. Ce fichier devra être compressé et placé dans le répertoire /boot. Une fois compressé avec gzip, bzip ou LZMA, la taille du noyau peut descendre aux 5-6 Mo qu'on attend pour un fichier du noyau Linux.

As for the drivers, their compiled and linked loadable module files have extension .ko (“kernel object”), and are distributed around the source tree side-by-side with the .c and .o files. For example, the IPv6 tunnel module will be found in compiled and linked form as net/ipv6/ip6_tunnel.ko. In order to execute our new kernel, we will need to perform four distinct actions: • The modules must be separated from the source files, and copied into directory /lib/modules/<kernel-name>/kernel. • The kernel itself must be compressed, and the compressed file placed in /boot. • The modules must also be integrated into an initrd (initial file system) compressed file, also placed in /boot. • We must also update the GRUB bootloader configuration so as to include the new kernel in the boot options.

En ce qui concerne les pilotes, leurs fichiers de modules chargeables compilés et liés portent l'extension .ko (« kernel objet » ou objet de noyau), et sont distribués dans l'arborescence source côte-à-côte avec les fichiers .c et .o. Par exemple, on trouvera le module de tunnel IPv6 sous forme compilée et liée dans net/ipv6/ip6_tunnel.ko.

Afin d'exécuter notre nouveau noyau, nous aurons besoin d'effectuer quatre actions distinctes : • Les modules doivent être séparés des fichiers sources et copiés dans le répertoire /lib/modules/<nom-du-noyau>/kernel. • Le noyau lui-même doit être compressé, et le fichier compressé placé dans /boot. • Les modules doivent également être intégrés dans un fichier compressé initrd (système de fichier initial), également placé dans /boot. • Nous devons également mettre à jour la configuration du gestionnaire de démarrage GRUB de manière à inclure le nouveau noyau dans les options de démarrage.

Luckily, there is a specific make target available to do all this automatically. Since we will be making changes in the system configuration, we will need to do it with administrator privileges – thus the “sudo” command. It is also the time when we can seriously break things in our system, so proceed with caution and only when satisfied the previous steps have taken place correctly. Then, to install the modules in /lib (step 1 above), issue: $ sudo bash # make modules_install You will see each .ko file pass by on screen as it is copied over. Now, we are ready to do the kernel itself. Issue: # make install and the script will perform steps 2, 3 and 4 all together for you. You will now see the output of the GRUB configuration tool grub-mkconfig on screen, and in directory /boot the new files will make their appearance: • vmlinuz-3.13.11.2 (or similar): the compressed kernel; • System.map-3.13.11.2 (or similar): a table of the symbols in the kernel, and their corresponding positions in memory; • initrd.img-3.13.11.2: the compressed file system (with modules generated from /lib) needed to perform initial system boot.

Heureusement, il y a une cible spécifique disponible pour que make fasse tout cela automatiquement. Puisque nous ferons des changements dans la configuration du système, nous devrons le faire avec des privilèges d'administrateur, donc la commande « sudo ». C'est aussi le moment où nous pouvons sérieusement casser des choses dans notre système, alors procédez avec prudence et uniquement lorsque vous êtes sûr que les étapes précédentes se sont déroulées correctement. Ensuite, pour installer les modules dans /lib (étape 1 ci-dessus), saisissez :

$ sudo bash

# make modules_install

Vous verrez chaque fichier .ko défiler sur l'écran pendant qu'il est recopié. Maintenant, nous sommes prêts pour faire le noyau lui-même. Saisissez :

# make install

et le script exécutera les étapes 2, 3 et 4 à la suite à votre place. Vous verrez alors la sortie de l'outil de configuration de GRUB grub-mkconfig à l'écran et les nouveaux fichiers feront leur apparition dans le répertoire /boot : • vmlinuz-3.13.11.2 (ou similaire) : le noyau compressé ; • System.map-3.13.11.2 (ou similaire) : une table des symboles dans le noyau et leurs positions correspondantes dans la mémoire ; • initrd.img-3.13.11.2 : le système de fichiers compressé (avec les modules générés à partir de /lib) nécessaire pour effectuer le démarrage initial du système.

TRYING OUT YOUR NEW KERNEL Since the automatic install process has taken care of the GRUB configuration for us, all we have to do now is reboot our computer. In the GRUB menu, the first entry we find is simply labeled “Ubuntu”, and this is the one corresponding to our new kernel. At least one other entry will be found underneath, labeled “Ubuntu 14.04 LTS” or similar. This is the older kernel, still available as a backup just in case the new kernel does not work as expected. Boot into the new kernel -just hit ENTER- and hopefully the system should come up. In fact, it should be rather difficult to note that the new kernel is being used. However, if we open a terminal and use the uname command, we should see the description and compile date of our new kernel: $ uname -a Linux alan-lenovo 3.13.11.2 #5 SMP Sat Jul 19 21:32:47 CEST 2014 x86_64 x86_64 x86_64 GNU/Linux

ESSAYER VOTRE NOUVEAU NOYAU

Puisque le processus automatique d'installation a pris soin de la configuration de GRUB pour nous, tout ce que nous avons à faire maintenant est de redémarrer l'ordinateur. Dans le menu de GRUB, la première entrée que nous trouvons est simplement « Ubuntu » et c'est celle qui correspond à notre nouveau noyau. Au moins une autre entrée sera présente en dessous, intitulée « Ubuntu 14.04 LTS » ou similaire. C'est l'ancien noyau, toujours disponible comme une sauvegarde au cas où le nouveau noyau ne fonctionnerait pas comme prévu.

Démarrez avec le nouveau noyau - avec la touche Entrée - et normalement le système devrait apparaître. En fait, il devrait être plutôt difficile de voir que le nouveau noyau est utilisé. Cependant, si nous ouvrons un terminal et utilisons la commande uname, nous devrions voir la description et la date de notre nouvelle compilation du noyau :

$ uname -a

Linux alan-lenovo 3.13.11.2 #5 SMP Sat Jul 19 21:32:47 CEST 2014 x86_64 x86_64 x86_64 GNU/Linux

This information can also be found by listing file /proc/version , while /proc/version_signature contains the free-form “Arbitrary version” character string we entered during configuration: $ cat /proc/version_signature Ubuntu 3.13.0-24.47-generic-alan If you have managed to follow us so far, congratulations! What you have just achieved is quite difficult - or nearly impossible for mortal humans - with most current operating systems. Now, have some fun and try out your new kernel. How does it compare with the old one? What about speed and memory usage? In the next part of this series, we will be looking into how to make some changes and apply simple tweaks to our kernel, and how they affect system performance.

Cette information peut également être trouvée en regardant dans le fichier /proc/version, tandis que /proc/version_signature contient la chaîne de caractères libre de la « version arbitraire » que nous avons saisie lors de la configuration :

$ cat /proc/version_signature

Ubuntu 3.13.0-24.47-generic-alan

Si vous avez réussi à nous suivre jusqu'ici, félicitations ! Ce que vous venez de réussir est assez difficile - ou presque impossible pour les humains mortels - avec la plupart des systèmes d'exploitation actuels. Maintenant, faites-vous plaisir et essayez votre nouveau noyau. Comment se compare-t-il avec l'ancien ? Qu'en est-il de la vitesse et de l'utilisation de la mémoire ?

Dans la prochaine partie de cette série, nous allons examiner la façon de faire des changements et d'appliquer des réglages simples à notre noyau, et comment ils affectent les performances du système.