Long ago and far away, compiling the kernel of a GNU/Linux system used to be what is called a rite of passage. You could not really call yourself a Linux enthusiast until you had painstakingly obtained the several different bits that form a working system - the kernel, the C compiler, perhaps also an X11 windowing system and several user programs - from different places on the Internet. The various bits and pieces would almost never work well together at first, so you needed to go through a process of compilation: i.e. transforming the source code of each program (in the C language) into an executable “binary file” - and the biggest and most complicated program was the system kernel itself. It should also be said that in those good old days, most if not all Linux users were in fact computer people by trade or by interests.
Il y a longtemps, très loin d'ici, la compilation du noyau d'un système GNU/Linux était ce qu'on appelle un rite de passage. Vous ne pouviez pas vous qualifier vous-même de passionné de Linux tant que vous n'aviez laborieusement obtenu un ensemble de bouts différents qui formaient un système en état de marche – le noyau, le compilateur C, peut-être aussi un système de fenêtrage X11 et plusieurs programmes utilisateurs – venant de différents sites du Net. Ces divers fragments ne fonctionnaient ensemble que rarement du premier coup, aussi vous aviez besoin de passer par le processus de compilation : c'est-à-dire la transformation du code source de chaque programme (en langage C) en un « fichier binaire » exécutable – et le programme le plus gros et le plus compliqué était le noyau lui-même.
Je dois dire aussi que, au bon vieux temps, la plupart sinon tous les utilisateurs de Linux étaient des informaticiens, professionnels ou amateurs.
Then came along several important steps towards making a GNU/Linux system more readily accessible to the average user. The first was the distribution, that collected all these software packages, compiled them in a coherent fashion and served them nicely bundled up in a CD image together with an installation program to make the process much more automatic. Slackware and RedHat were among the first distributions to make it to the general public, though many more came along afterwards. A second important step that also sets the GNU/Linux world at an advantage from other operating systems - at least to my mind - is the package manager. Being able to install software packages written by different authors or projects, all directly from a common repository, definitely makes system software management easier on the administrator – be it of a single machine, and all the more so when a park of several hundred computers must be set up in the same fashion.
Puis il y a eu plusieurs étapes vers la réalisation d'un système GNU/Linux d'un accès plus facile pour l'utilisateur moyen. Le premier fut la distribution, qui collectait tous ces paquets logiciels, les compilait d'une façon cohérente et les servait joliment regroupés dans une image sur CD avec un programme d'installation qui rendait le processus plus automatisé. Slackware et RedHat furent parmi les premières distributions à arriver devant le grand public, bien qu'ensuite de nombreux autres se soient présentés.
Un second pas important, qui donna un avantage au monde GNU/Linux par rapport aux autres systèmes – selon moi, s'entend – est le gestionnaire de paquets. Être capable d'installer des paquets logiciels écrits par différents auteurs ou projets, tous accessibles directement du même dépôt commun, rend sans conteste la gestion des logiciels système plus facile pour l'administrateur – lorsqu'il s'agit d'une machine isolée, bien entendu, mais encore plus quand un parc de plusieurs centaines de machines doit être paramétré de façon uniforme.
Finally, a third step happened with the Ubuntu distribution, when it changed the way the game was played and focused more closely on what in Apple's parlance is called the “user experience”: making it not only possible but easy and even enjoyable for non-technical users to set up a working box. This is not to say that previous distributions had not obtained some progress in this direction, but Ubuntu took the process a step further, with a streamlined installation program that did not require a PhD in computer science to understand, and a large selection of world languages available straight away during the installation process itself. The importance of being able to install a system with all the messages and dialogue boxes in your own language cannot be overstated. Although most computer technicians all over the world are quite capable of understanding technical information given in English, this may or may not be the case for normal people who must contend not only with the technical barrier, but also with a language they do not always fully grasp.
Enfin, une troisième étape fut franchie avec la distribution Ubuntu, quand elle a changé les règles du jeu et s'est focalisée plus étroitement sur ce qui est appelé dans le jargon Apple « l'expérience utilisateur » : rendre le réglage de la machine non seulement possible, mais aussi facile et même agréable pour les non-techniciens. Je ne veux pas dire que les autres distributions n'ont pas fait des progrès dans le même sens, mais Ubuntu a poussé le processus un pas plus loin, avec une installation fluide dont la compréhension ne nécessite pas un Bac+5 en sciences, et avec une large palette de langues disponibles immédiatement pendant le processus d'installation même. Pouvoir installer un système dont tous les messages et les boîtes de dialogue s'affichent dans votre propre langue est d'une importance qui ne peut pas être sous-estimée. Bien que la majorité des techniciens informatiques de par le monde soient capables de comprendre des informations techniques données en anglais, ce n'est pas forcément le cas des gens ordinaires qui doivent faire face non seulement à une barrière technique, mais aussi à une langue qu'ils ne comprennent pas toujours parfaitement.
At this point where we stand today, each and every GNU/Linux distribution offers at least one Linux kernel, or a main default kernel plus different optional kernels for those who need them. It has been years since most of us have actually needed to compile a kernel in anger, just to make a system work. So the question can be posed: is there really any more a valid reason for a user of a modern distribution to know how to do so? This is the point I will try to reply to in this first part of the series. We will give some insight into what a kernel is, what it does and why it may in some cases be necessary to change it. In a second installment, we will see what we need to get in order to compile a kernel, and take a first glance at the source code itself. Further along, we will actually configure and compile a kernel, and see how the result may be installed and used on our system. We will then be able to go through some simple kernel tweaks, among which the different processor options (e.g. PAE) will be discussed. This will bring us to performing some simple changes in the existing source code, and seeing what they do. Finally, we will go through creating some of our own code, in the form of a kernel module.
Au point où nous en sommes de nos jours, toute distribution GNU/Linux offre au moins un noyau Linux, ou un noyau principal par défaut, complété de différents noyaux optionnels pour ceux qui en ont besoin. De nombreuses années se sont écoulées depuis que la plupart d'entre nous avions réellement besoin de compiler un noyau en rageant, juste pour que le système fonctionne. Aussi la question peut se poser : Y a-t-il réellement une bonne raison pour que l'utilisateur d'une distribution moderne ait besoin de le faire ?
C'est à cette question que je vais essayer de répondre dans la première partie de cette série. Nous allons donner un aperçu de ce qu'est un noyau, de ce qu'il fait et des raisons pour lesquelles il peut être nécessaire de le changer dans certains cas. Dans un second épisode, nous verrons ce que nous devons obtenir pour être en mesure de compiler un noyau et jeter un premier coup d’œil au code source lui-même. Ensuite, nous configurerons et compilerons le noyau, puis nous verrons comment le résultat peut être installé et utilisé dans notre système. Nous serons alors en mesure de faire quelques ajustements simples au noyau, parmi lesquels les différentes options du processeur (par ex. PAE) seront étudiées. Ceci nous amènera à faire quelques changements simples dans le code source existant et en voir le résultat. Enfin, nous créerons un peu de code personnalisé, sous la forme d'un module du noyau.
WHAT IS THE LINUX KERNEL? On of the first diagrams that operating system students will see is the “onion” representing the different operating system layers. In this - very much simplified - version of the “onion”, we see the kernel at the center of the diagram. Surrounding it, we find a layer of libraries and system utility programs. Finally, the third and outermost layer is formed by user programs. It is important to understand the purpose of each layer. The kernel itself is a very low-level piece of software; that is to say, it is in immediate relationship with the hardware and manages the most basic functionalities of the operating system. These include: 1. Managing the processes and their access to CPUs. In a modern multiprocessing environment, computers have one or more CPUs available. Contrary to popular belief, each CPU core can in fact perform only simple tasks, and furthermore can execute only one single task in a given time-step. On the other hand, we wish to run more than one concurrent program at the same time: for example, we could very well be listening to some music with Exaile while we peruse a PDF issue of our favorite FullCircle in Evince and run an instance of Hexchat in the background. This means some part of our system needs to be available to segment each running program into short steps. Each step in then executed in turn on a CPU for a short period of time, after which it goes to sleep while other programs get access to the CPU. The process is then woken up once more and the next step is executed, and so on and so forth. The same system component that manages this will need to make sure each process gets a fair share of CPU time, that “zombie” processes are terminated, and so forth. This process management component - or “scheduler” - is part of the kernel.
QU’EST-CE QUE LE NOYAU LINUX ?
Un de premiers diagrammes que nos étudiants en système d'exploitation [OS] verront est l'« oignon » représentant les différentes couches de l'OS. Dans cette version de l'« oignon » – très très simplifiée – nous voyons le noyau au centre du diagramme. Autour de lui, nous trouvons une couche de bibliothèques (librairies) et d'utilitaires système. Enfin, la troisième couche, la plus extérieure, est constituée de programmes utilisateurs.
Il est important de comprendre le but de chaque couche : le noyau lui-même est un morceau de logiciel de très bas niveau ; autrement dit, c'est lui qui assure la liaison directe avec le matériel et gère les fonctionnalités les plus basiques de l'OS. Parmi lesquelles :
1. La gestion des traitements et leur accès au CPU
Dans un environnement multi-traitements, les ordinateurs disposent d'un ou de plusieurs processeurs. Contrairement à la croyance populaire, chaque cœur du CPU ne peut réaliser en fait que des tâches simples et, de plus, il ne peut exécuter qu'une tâche unique pendant un intervalle de temps. À contrario, nous souhaitons réaliser plusieurs tâches en parallèle au même moment. Par exemple, nous pourrions écouter de la musique avec Exaile pendant que nous consultons un numéro en PDF de notre revue favorite Full Circle avec Evince et qu'une instance de Hexchat tourne en arrière-plan. Ce qui implique qu'un élément de notre système soit disponible pour segmenter chaque programme en cours en petits tronçons. Chaque tronçon est alors exécuté à son tour dans le CPU pendant une courte période de temps, après quoi il s'endort pendant que d'autres tronçons ont accès au processeur. Ensuite, le traitement est une nouvelle fois réveillé et le tronçon suivant est exécuté, et ainsi de suite. Le même composant qui gère cela vérifiera que chaque traitement ait accès à un temps de CPU raisonnable, que les traitements « zombies » soient terminés, etc. Ce composant de gestion des traitements – ou « ordonnanceur » [Ndt : « scheduler » en anglais] – fait partie du noyau.
2. Managing memory. Once more, in a multiprocessing environment, each process will, at some point, require the usage of a certain amount of direct-access core memory (RAM). If we left memory management to the processes themselves, we could expect a fair amount of competition between them: who gets access to that last page of available RAM? So we need a centralized memory management system, to which individual processes apply for access to RAM. This is also a function of the kernel, which furthermore ensures each process accesses only the memory that has been assigned to it. If it should access a page of memory assigned to another process, something visibly has gone wrong and the kernel shall immediately terminate the offending process.
2. Gérer la mémoire
Une fois encore, dans un environnement multi-traitements, chaque traitement, d'une certaine manière, demandera l'usage d'une certaine quantité de mémoire vive (RAM = ramdom access memory). Si nous laissons les traitements gérer la mémoire eux-mêmes, nous pouvons nous attendre à une compétition soutenue entre eux : qui va avoir accès à la dernière page de mémoire disponible ? Aussi, nous avons besoin d'un système de gestion centralisé de la mémoire, auquel chaque traitement individuel s'adresse pour accéder à la mémoire vive. C'est aussi une fonction du noyau, qui vérifie en outre que chaque traitement n'accède qu'à la mémoire qui lui a été attribuée. S'il accède à une page de mémoire attribuée à un autre traitement, quelque chose ne va pas de façon évidente et le noyau devra immédiatement terminer le traitement fautif.
3. Managing access to Input/Output devices. Much in the same way as CPUs and memory, hardware devices must be shared between many processes. For example, we could consider a USB port to which a printer has just been connected. Which process gets to manage this? It is the kernel that must recognize the type of driver required for this model of printer, activate it and grant it exclusive access to the USB port while the hardware remains connected. All this can get quite involved as modern computers include new hardware types with passing time. So it is understandable that operating system kernels are just about the largest and most complex type of computer program the average user will encounter. On the other hand, a kernel that works really well is a necessity for any computing device. Otherwise, conflicts between different running programs could not be solved, hardware would cease to be available to the software, the hard drives themselves could not be accessed, etc.
3. Gérer les accès aux dispositifs d'entrée/sortie
D'une façon assez voisine qu'avec le CPU et la mémoire, les dispositifs matériels doivent être partagés entre plusieurs traitements. Par exemple, prenons le cas d'un port USB auquel une imprimante a été connectée. Quel traitement va gérer cela ? C'est le noyau qui doit reconnaître quel type de pilote est nécessaire pour ce modèle d'imprimante, qui doit l'activer et qui doit lui garantir un accès exclusif au port USB tant que l'imprimante reste connectée.
Tout ceci peut devenir relativement compliqué puisque, au fur et à mesure, les ordinateurs modernes incorporent de nouveaux types de matériels. Ainsi, affirmer que le noyau d'un système d'exploitation est la partie du logiciel d'ordinateur la plus grosse et la plus compliquée que l'utilisateur moyen pourra rencontrer, est tout à fait logique.
D'autre part, avoir un noyau qui fonctionne parfaitement bien est une nécessité pour tout dispositif informatique. Sinon, les conflits entre les différents programmes travaillant en parallèle ne pourraient être résolus, le matériel cesserait d'être disponible pour les programmes, il ne serait plus possible d'accéder aux disques durs eux-mêmes…
Going back to the “onion” diagram, each successive layer can request the services of layers situated inwards of themselves. System libraries and programs are respectively formed of libraries that contain much-used routines on one hand, and simple programs that any operating system would need on the other. An example of the first is the glibc library, that most if not all programs in a GNU/Linux will require. This contains many often-used routines such as writing a character string on screen, accessing a file, or writing to a network port. An example of a system program could be the mkfs.ext4 utility to format an ext4 partition. These libraries and programs will at some point need to access physical system resources, be it memory or a hardware device. At that point they will request this service from the inner kernel layer, using what is called a “system call”.
Pour revenir au diagramme de l'« oignon », chaque couche successive peut demander les services des couches situées plus à l'intérieur. Les bibliothèques du système et les programmes sont respectivement formés de bibliothèques qui contiennent des routines très utilisées d'une part, et de simples programmes nécessaires à tout système d'exploitation d'autre part. Pour illustrer le premier cas, la bibliothèque glibc [Ndt : « lib » pour « librarie », autrement dit bibliothèque] est requise dans chacun (ou presque) des systèmes GNU/Linux. Elle contient beaucoup de routines très utilisées telles qu'écrire une chaîne de caractères sur un écran, accéder à un fichier, ou écrire sur un port réseau. L'utilitaire mkfs.ext4, qui formate une partition en ext4, est, lui, un exemple de programme système. Ces bibliothèques et ces programmes auront besoin à un moment donné d'accéder aux ressources physiques du système, que ce soit de la mémoire ou un dispositif matériel. À ce moment-là, ils vont solliciter ce service auprès de la couche intérieure du noyau, utilisant ce qui est nommé un « appel système ».
This request may or may not succeed, depending on whether the requested resource is at that time available to the kernel. Certain security policies may also be in place, restricting access to resources depending on the type of program on the identity of the user on behalf of whom it is executing. In any case, the program making the request cannot directly access the resource without checking whether the kernel has granted access, although some programs have been seen to do so. The ‘not taking access for granted’ is one of the differences between well-written and that less well-implemented software. Many libraries and system programs will be needed on all computers running a given version of the operating system. Continuing outwards in the diagram, we find the user programs. These may vary from installation to installation, depending on the specific use given to the system. They will also require the service of the layers inwards of them, both of the kernel itself and also of the system libraries. For example, a web browser will request some free memory from the kernel when it starts up, in which to store pages accessed on the Internet. But if the user should access a web page through the encrypted HTTPS protocol, the browser will also require the services of the openssl library and its routines to set up a secure channel to the server – to encrypt and decrypt data.
Cette demande peut réussir ou pas, selon que la ressource soit disponible au noyau ou non à ce moment-là. Certaines règles de sécurité peuvent aussi être en place, pour restreindre l'accès aux ressources en fonction du type de programme et selon l'identité de l'utilisateur pour lequel il est exécuté. Dans tous les cas, le programme demandeur ne peut pas accéder à la ressource sans vérifier si le noyau lui a accordé l'accès, bien qu'on ait vu des programmes le faire. Le fait de « ne pas tenir l'accès pour acquis » est une des différences entre des programmes bien écrits et d'autres moins bien construits.
Beaucoup de bibliothèques et de programmes système seront nécessaires sur tous les ordinateurs utilisant une version donnée du système d’exploitation.
En poursuivant la découverte du diagramme vers l’extérieur, nous trouvons les programmes utilisateur. Ils peuvent varier d’une installation à l’autre, en fonction de l’utilisation spécifique du système. Ils auront aussi besoin des services des couches plus intérieures, à la fois du noyau et aussi des « libraries » (bibliothèques) système. Par exemple, un navigateur internet devra demander de la mémoire libre au noyau quand il démarre, pour stocker les pages internet auxquelles il accède. Mais si l’utilisateur doit accéder à une page Web par l’intermédiaire d’un protocole sécurisé HTTPS, le navigateur demandera aussi les services de la librarie openssl et de ses routines pour établir un canal sécurisé avec le serveur – pour encoder et décoder les données.
This explains many of the package dependencies that arise when installing new software: the maintainers of the web browser will have introduced a dependency on the openssl package, to make sure that the openssl is installed and with an appropriate version number when the browser fires up a HTTPS connection. Some readers may have noticed that purists - such as myself - tend to refer to our operating system as the “GNU/Linux” system, instead of the more abbreviated “Linux”. This is the terminology used by the Free Software Foundation and the Debian Project, among others. It recognizes the fact that in our operating system the kernel is developed by one project, started by Linus Torvalds and hosted at www.kernel.org. This kernel is in fact the only part of the system that can be called “Linux”.
Ceci explique les nombreuses dépendances qui apparaissent quand un nouveau logiciel est installé : les développeurs du navigateur internet auront introduit une dépendance vers le paquet openssl, pour être sûrs que openssl est installé, avec le bon numéro de version, quand le navigateur internet établira une connexion HTTPS.
Certains lecteurs auront peut-être remarqué que les puristes – dont je suis – ont tendance à faire référence au système d’exploitation comme le système « GNU/Linux » au lieu de l’abréviation « Linux ». C’est la terminologie utilisée par la Free Software Foundation [Fondation pour le Logiciel Libre] et le projet Debian, parmi d’autres. Cela reconnaît le fait que, dans le système d’exploitation, le noyau est développé par un seul projet, initié par Linus Torvalds lui-même, et hébergé à www.kernel.org. Ce noyau est en fait la seule partie du système qui peut être appelée « Linux ».
On the other hand, some of the most important bits of the operating system software have been developed in conjunction with the GNU Project at www.gnu.org, which is now sponsored by the Free Software Foundation (FSF). This includes the C language compiler, gcc. The GNU Project also has its own kernel, the GNU Hurd, which is quite different from the Linux kernel, and in some respects perhaps more advanced. So, by combining different kernels and keeping the rest of the operating system software, we can obtain our well-known GNU/Linux, but also GNU/FreeBSD with the FreeBSD kernel or GNU/Hurd that combines the GNU system software with the also GNU Hurd kernel. What does not help clarify the situation is that, for some time now, the Linux kernel is also released under the very same GNU General Public License (GPL) as the GNU Project software. So let us just take away that the kernel and the accompanying software of the GNU/Linux are released by different teams and leave it at that. Needless to say, many user programs have been developed in further projects, unrelated either to the Linux project or to GNU. Their software may be released under GPL, or other licenses such as the Apache license, the BSD license, or others - even commercial licenses.
D’un autre côté, une partie des éléments les plus importants du système d’exploitation ont été développés en collaboration avec le projet GNU (www.gnu.org), qui est sponsorisé maintenant par la Free Software Foundation (FSF). Cela comprend le compilateur de langage C, gcc. Le projet GNU a aussi son propre noyau, le GNU Hurd, qui est très différent du noyau Linux et, sur certains aspects, plus avancé. Aussi, en combinant les différents noyaux et en conservant le reste du logiciel du système d’exploitation, nous pouvons obtenir notre bien connu GNU/Linux, mais aussi le noyau GNU/FreeBSD avec le noyau FreeBSD ou le GNU/Hurd qui combine le logiciel système GNU avec le noyau Hurd, lui aussi GNU.
Ce qui n'aide pas à simplifier la situation est que, depuis pas mal de temps, le noyau Linux est publié sous la même licence GNU General Public License (GPL) [Licence publique générale - Wikipedia] que le logiciel du projet GNU. Alors contentons-nous de nous rappeler que le noyau et le logiciel conjoint de GNU/Linux sont publiés par des équipes différentes et restons-en là. Il va sans dire que beaucoup de programmes utilisateur ont été développés dans des projets ultérieurs, sans rattachement au projet Linux ni au GNU. Leurs logiciels peuvent être publiés sous licence GPL ou d’autres licences telles que la licence Apache, la licence BSD, ou d’autres – même des licences commerciales.
WHY COMPILE YOUR OWN KERNEL? Now that we know what the Linux kernel is, we can discuss a bit why it could be interesting for the user of a modern system to compile his or her very own kernel. There are several reasons for this. A first point that must be made is that not all processors are equal. If we stay within the Intel product line, basically we can find two different CPU families. The first is based on the 80386 (or “i386”) model released in 1985. This was a 32-bit processor, meaning that numerical operations could be executed on operands 32-bits in length. It also means that memory addresses could use 32-bits, so each process could “address” (use) up to 2^32 address locations. This translates to a memory space of up to 4GBytes, which seemed extraordinarily large at the time.
POURQUOI COMPILER SON PROPRE NOYAU ?
Maintenant que nous savons ce qu’est un noyau, étudions un peu pourquoi il pourrait être intéressant pour l'utilisateur d’un système moderne de compiler son propre noyau.
Il y a plusieurs raisons à cela. Le premier point, c’est que tous les processeurs ne sont pas égaux. Si vous restez dans la ligne de produits Intel, on peut à première vue distinguer 2 familles différentes de CPU. La première est basée sur le modèle 80386 (ou « i386 ») commercialisé en 1985. C’était un processeur 32-bit, ce qui veut dire que les calculs pouvaient être effectués avec des opérandes de 32 bits de long. Cela signifie aussi que les adresses mémoire étaient sur 32 bits ; ainsi, chaque traitement pouvait « adresser » (utiliser) jusqu’à 2^32 adresses mémoire. Ceci correspond à un espace mémoire de 4 Goctets, ce qui semblait extrêmement grand pour l’époque.
Over the years, succeeding derivatives of the i386 (the i486, Pentium, Pentium Pro, Pentium II and III, the Pentium IV and finally the Atom) incorporated more and more features. However, these processors of the “Intel Architecture, 32-bits” or IA32 family maintained the backwards compatibility of their instruction set. That is to say that the i486, for example, introduced new functionality compared to the i386, and the corresponding new instructions were added. However, it could understand perfectly all the i386's instructions, so a program compiled for the i386 would use just the i386's instruction set, and work on both processors – just a mite faster on the i486. This backwards compatibility was also maintained when AMD developed the 64-bit architecture that is now used in 64-bit personal computer systems. Processors include both AMD's own line of processors, but also Intel's Core Duo, Core i3, i5 and i7 offerings. These can work in 32-bit mode, just like a 32-bit processor – which explains why, for example, the 32-bit Windows XP could be used until recently with modern processors. However, in order to take advantage of the 64-bit instruction set, we need to compile our programs and kernel explicitly for this architecture. They will then be able to execute numerical operations on operands that are 64-bits long, and use longer memory addresses to access larger memory sizes. GNU/Linux distributions contain kernels that are compiled for a certain model of processor. Nowadays, most 32-bit kernels are compiled using the “i686” instruction set of the Pentium Pro CPU model.
Au fil des années, des dérivés successifs du i386 (les i486, Pentium, Pentium Pro, Pentium II et III, Pentium IV, et enfin Atom) ont incorporé de plus en plus de fonctionnalités. Cependant ces processeurs d’« architecture Intel 32 bits » ou famille IA32 perpétuaient la compatibilité ascendante de leur jeu d’instructions. Ce qui veut dire, par exemple, que le i486, par comparaison au i386, ajoutait une fonctionnalité nouvelle ce qui ajoutait de nouvelles instructions. Cependant il comprenait parfaitement toutes les instructions du i386 ; ainsi un programme compilé pour le i386 utilisait juste le jeu i386 et tournait sur les deux processeurs, juste un tout petit peu plus rapidement sur le i486.
La compatibilité ascendante a été aussi maintenue par AMD quand il a développé l’architecture 64-bit qui est maintenant utilisée dans les ordinateurs individuels 64-bit. Ces processeurs comprennent la propre ligne des processeurs AMD, mais aussi la gamme Intel Core Duo, Core i3, i5 et i7. Ils peuvent fonctionner sur 32 bits, comme un processeur 32-bit – ce qui explique pourquoi, par exemple, Windows XP 32-bit pouvait être utilisé encore récemment sur les machines modernes. Cependant, pour profiter de l’avantage du jeu d’instructions sur 64 bits, nous avons besoin de compiler expressément les programmes et le noyau pour cette architecture. Ils seront alors capables d’exécuter des calculs avec des opérandes de 64 bits de long et utiliser des adresses mémoires plus étendues dans un espace mémoire plus vaste.
Les distributions Gnu/Linux contiennent des noyaux qui sont compilés pour un certain modèle de processeur. De nos jours, la plupart des noyaux 32-bits sont compilés avec le jeu d’instructions « i686 » du modèle de CPU Pentium Pro.
At the time of writing, the two kernel packages available for Ubuntu 14.04 are: http://archive.ubuntu.com/ubuntu/pool/main/l/linux/md-modules-3.13.0-31-generic-di_3.13.0-31.55_i386.udeb for the IA32 i686 instruction set – even though the “i386” indication has been maintained in the package names; http://archive.ubuntu.com/ubuntu/pool/main/l/linux/md-modules-3.13.0-31-generic-di_3.13.0-31.55_amd64.udeb for the amd64 (also known as x86-64) instruction set. This means two things: • a i686 kernel will not work on earlier models, since a i386, i486 or Pentium lack some of the instructions used. This will either simply not work at all, or may freeze during execution. • a i686 kernel will work on later models, but will not be optimized since the more recent instructions available on an Atom processor (that was released in 2008) will not be used by the kernel. An example of this is the famous “Physical Address Extension” (PAE) instruction set. This extension of the original IA32 instruction set allowed processors to connect to and use larger memory address sizes than the 32-bit limit set by the i386.
A l’heure où j’écris, les deux paquets de noyaux disponibles pour Ubuntu 14.04 sont : http://archive.ubuntu.com/ubuntu/pool/main/l/linux/md-modules-3.13.0-31-generic-di_3.13.0-31.55_i386.udeb pour le jeu d’instruction du IA32 i686 – même si l’indication « i386 » a été maintenue dans la dénomination du paquet ;
http://archive.ubuntu.com/ubuntu/pool/main/l/linux/md-modules-3.13.0-31-generic-di_3.13.0-31.55_amd64.udeb pour le jeu d’instructions du amd64 (connu aussi comme x86-64).
Cela signifie deux choses : • un noyau i686 ne fonctionnera pas du tout, ou fera planter la machine, sur des modèles anciens, parce qu’un i386, i486 ou Pentium ne comprendra pas certaines instructions utilisées ; • un noyau i686 fonctionnera sur les modèles récents, mais il ne sera pas optimisé car certaines instructions récentes disponibles sur un processeur Atom (commercialisé en 2008) ne seront pas utilisées par le noyau.
Un exemple en est le fameux jeu d’instructions de l’ « extension des adresses physiques » [PAE = Physical Adress Extension]. Cette extension au jeu d’instructions original IA32 permettait aux processeurs de se connecter et d’utiliser des tailles d’adresse mémoire plus grandes qu’avec le jeu limité des 32-bits du i386.
Originally presented in the Pentium Pro generation of Intel processors, PAE became standard in most Pentium-III desktop and all Pentium-IV and Core series. This should include most personal computers that have been sold during the last ten years. So most people will not need to worry if our favorite distribution (Ubuntu) is activating PAE by default in its kernels since version 12.10, and so making PAE presence mandatory in the CPU. Ubuntu 14.04 will no longer work on processors without it, though other (earlier) distributions may run. Even if we exclude users of really old hardware, a certain class of laptop that is still current in terms of usability suffers from the lack of PAE. Laptops built on Intel’s Pentium M (“M” for “Mobile”) processors present several advantages on later Pentium IV, M or Core CPUs. This processor class is based on the Pentium III, which is known to be internally less complex that later Pentium IVs. In practice, they compute faster when run at the same clock speed, and so are more energy efficient and manage laptop battery life better.
Proposé à l’origine dans la génération Pentium Pro des processeurs Intel, PAE devint un standard dans beaucoup de PC Pentium-III, dans tous les Pentium-IV et dans la série Core. Ceci devrait concerner de très nombreux ordinateurs personnels qui ont été vendus au cours des dix dernières années. Aussi, la plupart des gens n’ont pas besoin de se demander si leur distribution favorite (Ubuntu) active PAE par défaut dans son noyau depuis la version 12.10 et ainsi rend obligatoire l’activation du PAE sur le processeur. Ubuntu 14.04 ne fonctionnera plus sur des processeurs où il est absent, alors que d’autres distributions (plus anciennes) pourraient tourner.
Même si nous excluons les utilisateurs de très vieux matériels, une certaine partie des portables qui sont encore d’usage courant souffre de cette absence du PAE. Les portables construits sur les processeurs Intel Pentium M (« M » pour « Mobile ») présentent plusieurs avantages sur des processeurs plus récents Pentium IV, M ou série Core. Cette classe de processeurs est basée sur le Pentium III, qui est connue pour son architecture interne moins complexe que celle du Pentium IV plus récent. En pratique, elle calcule plus vite pour une même vitesse d’horloge, elle est aussi plus économe en énergie et présente une meilleure gestion de la batterie du portable.
So it makes sense for owners of computers, such as the original eeePC or some of the first 17” laptops, to try and keep them going - especially since, with a lightweight distribution such as Lubuntu or Xubuntu, they are still well up to most normal web browsing or office tasks. Several solutions can be found on the web, for example those described in “Enabling PAE” (https://help.ubuntu.com/community/EnablingPAE) and “Lubuntu-fake-PAE” (https://help.ubuntu.com/community/Lubuntu-fake-PAE) on the Ubuntu community documentation server. However, simply compiling and using a kernel with PAE disabled solves the problem once and for all. The same could be said for earlier processors. The Debian project still supported i386 kernel until recently, though the new base line is the i486 instruction set (see http://www.debian.org/releases/sarge/i386/release-notes/ch-upgrading.en.html). It makes sense for distribution maintainers to concentrate their efforts on newer architectures that are more abundant in actual use, even though this means support for earlier models will slowly but surely disappear. In this case, too, running a recent distribution on older machines will imply even more often compiling your own kernel.
On comprend mieux pourquoi certains propriétaires de PC, comme les eeePC originaux ou certains des premiers portables 17“, essaient de les garder en état de marche – en particulier parce que, avec des distributions légères comme Lubuntu ou Xubuntu, ils sont toujours bien taillés pour la navigation internet ou les tâches bureautiques.
Plusieurs solutions peuvent être trouvées sur le Web, notamment celles décrites dans « Enabling PAE » [Activer PAE] (https://help.ubuntu.com/community/EnablingPAE) ou « Lubuntu-fake-PAE » [fausse PAE dans Lubuntu] (https://help.ubuntu.com[/community/Lubuntu-fake-PAE) sur le serveur de la documentation de la communauté. Cependant, on résout simplement le problème une fois pour toutes en compilant le noyau avec PAE désactivé.
On pourrait dire la même chose des processeurs plus anciens. Le projet Debian supportait le noyau i386 jusqu’à récemment, alors que la nouvelle référence est le jeu d’instructions i486 (voir http://www.debian.org/releases/sarge/i386/release-notes/ch-upgrading.en.html). Il est compréhensible que les développeurs concentrent leurs efforts sur les nouvelles architectures qui sont utilisées en plus grand nombre actuellement, même si cela signifie que le support des modèles plus anciens va disparaître lentement mais sûrement. Aussi, dans ce cas, l’usage de distributions récentes sur de vieux ordinateurs impliquera une compilation plus fréquente de votre propre noyau.
As for more recent machines, there are also arguments in favor of compiling your own kernel. The standard i686 kernel will work quite well on modern hardware, but will not be able to use the more recent architecture developments. This is the point of view of the Gentoo distribution, that allows the user to compile each and every software package installed (http://wiki.gentoo.org/wiki/FAQ), leading to a globally more efficient and leaner installation. Even if we do not need a complete new kernel, in some cases, when a user needs to use relatively new hardware, it becomes necessary to compile at least the relevant driver. Graphics controllers and wireless communication devices are among the potential candidates. The new driver is a modular part of the kernel, that plugs into the existing kernel to give it the capabilities to handle the hardware. And finally, perhaps the best reason for compiling a kernel is simply because it can be done. Few other mainstream operating system users can say they have compiled a main part of their systems – but we can. Along the way, we will also be learning a lot about how our computer and its software actually work.
Quant aux machines récentes, il y a aussi des arguments en faveur de la compilation de votre propre noyau. Le noyau standard i686 fonctionnera très bien sur du matériel récent, mais ne sera pas capable d’utiliser les développements récents de l’architecture. C’est le point de vue de la distribution Gentoo, qui permet à l’utilisateur de compiler chaque paquet logiciel installé (http://wiki.gentoo.org/wiki/FAQ), aboutissant à une installation plus efficace et plus légère.
Même si nous n’avons pas besoin d’un nouveau noyau complet, dans certains cas, quand l’utilisateur veut utiliser un matériel assez nouveau, il devient nécessaire de compiler au moins le pilote concerné. Les contrôleurs graphiques et les dispositifs de communication sans fil sont parmi les candidats potentiels. Le nouveau pilote est une partie modulaire du noyau qui se branche au noyau existant pour lui donner les capacités de gérer le matériel.
Et au final, peut-être la meilleure raison de compiler un noyau est simplement parce qu’on peut le faire. Peu d’utilisateurs des systèmes d’exploitation dominants peuvent dire qu’ils ont compilé une partie importante de leur système, mais nous, on peut le dire. Pendant toute la série, nous allons aussi apprendre beaucoup sur le fonctionnement réel de notre ordinateur et de ses logiciels.
THE NECESSARY HARDWARE In the next few episodes, we will be going through the process of first obtaining the source code, and then actually compiling and installing a kernel. I will be using a fresh installation of Ubuntu 14.04 on a Core i5 laptop to perform example operations. The reader is encouraged to go ahead and do the same. However, the usual caveats apply: installing a new kernel is a major operation on your system. Though things should usually go well, there is some potential for breaking stuff, and needing to reinstall the system from scratch. So this is definitely a process that you should not do on a production machine. On the other hand, compiling a kernel will need some raw CPU power. Though it should be possible on a low consumption processor (such as a small netbook), it will benefit greatly from a heavyweight laptop or desktop CPU. An Intel Core Duo, Core i3 or similar is probably the slowest processor that could be recommended for this purpose. You should also be aware that the source code itself and the kernel files once compiled can take up to 20GB of disk space (mostly in the /usr directory), and plan accordingly. Whatever route you choose to go, please do make sure your own data is backed up before proceeding.
LE MATERIEL NECESSAIRE
Dans les tout prochains épisodes, nous allons parcourir les étapes pour obtenir d’abord le code source et ensuite compiler et installer un noyau. J’utiliserai une nouvelle installation de Ubuntu 14.04 sur un portable Core i5 pour réaliser des opérations à titre d'exemples. Le lecteur est encouragé à commencer en faisant de même. Cependant, les mises en garde habituelles s’imposent : l’installation d’un nouveau noyau est une opération majeure pour votre système. Bien que les choses se passent bien en général, il y a toujours un risque de casser quelque chose et de devoir réinstaller complètement le système. Donc, c’est un processus que vous ne devez en aucun cas faire sur une machine de production.
D’autre part, la compilation du noyau va consommer une grosse puissance CPU. Bien que ce soit toujours possible sur un système faible consommation (genre petit portable), vous y gagnerez en utilisant le CPU d’un gros portable ou d’un PC de bureau. Un Intel Core Duo, Core i3 ou équivalent est probablement le processeur le plus lent recommandable pour cette activité. Vous devez aussi savoir que le code source lui-même et les fichiers du noyau occuperont jusqu’à 20 Go d’espace disque (principalement dans le répertoire /usr) ; préparez-vous en conséquence.
Quelle que soit la voie que vous choisissez, veuillez vous assurer que vos données sont sauvegardées avant de commencer.