| Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
| issue89:labo_linux_2 [2015/02/10 15:58] – [1] auntiee | issue89:labo_linux_2 [2015/02/10 17:24] (Version actuelle) – [17] auntiee |
|---|
| # cd /usr/src/linux-source-3.13.0 | # cd /usr/src/linux-source-3.13.0 |
| |
| et décompressez le fichier à l'aide de l'utilitaire bunzip2. L'algorithme de compression bzip donne une meilleure compression que le gzip, plus commune, mais au détriment d'une plus grande complexité. Donc ne soyez pas surpris si la décompression prend un certain temps ! | et décompressez le fichier à l'aide de l'utilitaire bunzip2. L'algorithme de compression bzip donne une meilleure compression que le gzip, plus commune, mais au détriment d'une plus grande complexité. Ainsi, ne soyez pas surpris si la décompression prend un certain temps ! |
| |
| S'il n'est pas présent sur votre système, vous devez d'abord télécharger et installer le programme bzip : | S'il n'est pas présent sur votre système, vous devez d'abord télécharger et installer le programme bzip : |
| et maintenant /usr/src/linux pointe vers le répertoire réel /usr/src/linux-source-3.13.0/linux-source-3.13.0. Nous pouvons aussi faire un peu de nettoyage des fichiers compressés, si nous n'en avons plus besoin. | et maintenant /usr/src/linux pointe vers le répertoire réel /usr/src/linux-source-3.13.0/linux-source-3.13.0. Nous pouvons aussi faire un peu de nettoyage des fichiers compressés, si nous n'en avons plus besoin. |
| |
| Une autre façon d'obtenir les sources du noyau est de les récupérer simplement depuis le projet kernel.org. Cela nous garantit d'obtenir la toute dernière version du noyau, et aussi d'accéder aux candidats de la prochaine version à venir. Au moment où j'écris, la version de source du noyau Ubuntu est 3.13.0, mais kernel.org est déjà passé à 3.15.4, et la version du candidat pour la prochaine version est la 3.16. | Une autre façon d'obtenir les sources du noyau est de les récupérer simplement depuis le projet kernel.org. Cela nous garantit d'obtenir la toute dernière version du noyau, et aussi d'accéder aux candidates de la prochaine version à venir. Au moment où j'écris, la version de source du noyau Ubuntu est la 3.13.0, mais kernel.org est déjà passé à 3.15.4, et la version candidate pour la prochaine version est la 3.16. |
| |
| ====== 4 ====== | ====== 4 ====== |
| These older versions may come in handy, either to replicate the behavior of a system with an earlier configuration, or because a certain application needs a kernel from an earlier series. For example, an old hardware driver module available in source code may need a kernel source from the 2.0 series in order to compile correctly. These are probably fringe cases, however, and will rarely be seen by most users.** | These older versions may come in handy, either to replicate the behavior of a system with an earlier configuration, or because a certain application needs a kernel from an earlier series. For example, an old hardware driver module available in source code may need a kernel source from the 2.0 series in order to compile correctly. These are probably fringe cases, however, and will rarely be seen by most users.** |
| |
| Un mot d'avertissement peut être approprié, cependant : les noyaux qui ne sont pas de la version stable actuelle n'ont pas subi l'ensemble du processus de test. Ils vont inclure de nouvelles fonctionnalités, et peuvent éventuellement casser votre installation. Si vous n'avez pas besoin de tester ces futures versions, il est préférable de rester sur les stables. | Un mot d'avertissement peut être approprié, cependant : les noyaux qui ne sont pas de la version stable actuelle n'ont pas subi l'ensemble du processus de tests. Ils vont inclure de nouvelles fonctionnalités et peuvent éventuellement casser votre installation. Si vous n'avez pas besoin de tester ces futures versions, il est préférable de rester sur les stables. |
| |
| D'autre part, plusieurs anciennes versions stables des sources du noyau sont également disponibles sur kernel.org ; au moment de la rédaction on pouvait redescendre à la 2.6.32. Il convient de noter que ces versions antérieures ont été mises à jour avec des corrections de bogues et des mises à jour de sécurité depuis qu'elles sont sorties ; ce qui manque dans les versions antérieures ce sont essentiellement les nouvelles fonctionnalités qui sont sorties dans les nouvelles versions. | En revanche, plusieurs anciennes versions stables des sources du noyau sont également disponibles sur kernel.org ; au moment de la rédaction, on pouvait redescendre à la 2.6.32. Il convient de noter que ces versions antérieures ont été mises à jour avec des corrections de bogues et des mises à jour de sécurité depuis leur sortie ; ce qui manque dans les versions antérieures ce sont essentiellement les nouvelles fonctionnalités qui sont sorties dans les nouvelles versions. |
| |
| Ces anciennes versions peuvent être utiles, soit pour reproduire le comportement d'un système avec une configuration ancienne, soit parce qu'une certaine application a besoin d'un noyau d'une série antérieure. Par exemple, un ancien module de pilote de matériel disponible dans le code source peut avoir besoin des sources de la série 2.0 du noyau afin de compiler correctement. Cependant, ce sont probablement des cas marginaux, qui sont rarement rencontrés par la plupart des utilisateurs. | Ces anciennes versions peuvent être utiles, soit pour reproduire le comportement d'un système avec une configuration ancienne, soit parce qu'une certaine application a besoin d'un noyau d'une série antérieure. Par exemple, un ancien module de pilote de matériel disponible dans le code source peut avoir besoin des sources de la série 2.0 du noyau afin de compiler correctement. Cependant, ce sont probablement des cas marginaux, qui sont rarement rencontrés par la plupart des utilisateurs. |
| 634M linux-source-3.13.0 | 634M linux-source-3.13.0 |
| |
| La version d'Ubuntu est légèrement plus grosse, même si elle contient une version antérieure du noyau. Cela confirme qu'Ubuntu a en effet modifié le noyau d'une certaine façon. Les différences sont ce qu'Ubuntu appelle les « patches Ubuntu » au noyau. Le lecteur intéressé trouvera plus d'informations sur l'équipe du noyau d'Ubuntu et ce qu'ils font sur leur page wiki : https://wiki.ubuntu.com/Kernel | La version d'Ubuntu est légèrement plus grosse, bien qu'elle contienne une version antérieure du noyau. Cela confirme qu'Ubuntu a en effet modifié le noyau d'une certaine façon. Les différences sont ce qu'Ubuntu appelle les « patches Ubuntu » au noyau. Le lecteur intéressé trouvera plus d'informations sur l'équipe du noyau d'Ubuntu et ce qu'ils font sur leur page wiki : https://wiki.ubuntu.com/Kernel |
| |
| ====== 7 ====== | ====== 7 ====== |
| EXPLORATION DE L'ARBORESCENCE DES SOURCES | EXPLORATION DE L'ARBORESCENCE DES SOURCES |
| |
| Quand nous jetons un œil à l'arborescence du code source, nous voyons d'abord plusieurs fichiers texte immédiatement à la racine. Comme toujours, le fichier README est un excellent endroit pour commencer. Ce fichier contient quelques instructions rapides pour vous permettre de démarrer. Toutefois, certaines parties sont un peu obsolètes, par exemple la référence au gestionnaire de démarrage LILO qui est peu utilisé de nos jours, et pas du tout sur les distributions Ubuntu. Les fichiers CREDITS et MAINTAINERS contiennent une liste de personnes qui ont contribué au code du noyau et quelques-unes des parties dont ils ont été responsables. La lecture de ces deux fichiers peut nous donner un aperçu du travail d'équipe des programmeurs, qui mène à la construction du noyau. Linus Torvalds et Greg Kroah-Hartman sont peut-être les participants les plus connus et les chefs de projet, mais ils ne sont vraiment pas seuls. | Quand nous jetons un œil à l'arborescence du code source, nous voyons d'abord plusieurs fichiers texte immédiatement à la racine. Comme toujours, le fichier README est un excellent point de départ. Ce fichier contient quelques instructions rapides pour vous permettre de démarrer. Toutefois, certaines parties sont un peu obsolètes, par exemple la référence au gestionnaire de démarrage LILO qui est peu utilisé de nos jours, et pas du tout sur les distributions Ubuntu. Les fichiers CREDITS et MAINTAINERS contiennent une liste de personnes qui ont contribué au code du noyau et quelques-unes des parties dont ils ont été responsables. La lecture de ces deux fichiers peut nous donner un aperçu du travail d'équipe des programmeurs, qui mène à la construction du noyau. Linus Torvalds et Greg Kroah-Hartman sont peut-être les participants les plus connus et les chefs de projet, mais ils ne sont vraiment pas seuls. |
| |
| Le répertoire Documentation est une collection volumineuse et pas très bien structurée, principalement de notes (très) techniques. La plupart des documents ici se rapporte à des configurations matérielles et des procédures spécifiques au noyau, et sera malheureusement de peu d'aide pour le débutant. | Le répertoire Documentation est une collection volumineuse et pas très bien structurée, principalement de notes (très) techniques. La plupart des documents ici se rapporte à des configurations matérielles et des procédures spécifiques au noyau, et sera malheureusement de peu d'aide pour le débutant. |
| Un autre répertoire important est drivers. Avec le répertoire sound (contenant les pilotes spécifiques pour les matériels de traitement du son) et plusieurs autres répertoires mineurs, c'est ici que vous trouverez les pilotes pour chaque type de matériel que le noyau prend en charge. Fondamentalement, s'il y a du code dans ce répertoire qui sait comment gérer votre matériel, il pourrait fonctionner dans un système GNU/Linux. Sinon, ça risque d'être vraiment compliqué de le faire fonctionner. | Un autre répertoire important est drivers. Avec le répertoire sound (contenant les pilotes spécifiques pour les matériels de traitement du son) et plusieurs autres répertoires mineurs, c'est ici que vous trouverez les pilotes pour chaque type de matériel que le noyau prend en charge. Fondamentalement, s'il y a du code dans ce répertoire qui sait comment gérer votre matériel, il pourrait fonctionner dans un système GNU/Linux. Sinon, ça risque d'être vraiment compliqué de le faire fonctionner. |
| |
| Gardez s'il vous plaît à l'esprit que chaque bout de code d'un pilote dans ce répertoire ne s'occupe pas d'une marque particulière de matériel, mais plutôt des puces du contrôleur utilisées dans ce matériel. Par exemple, dans le répertoire drivers/net/ethernet/realtek nous pouvons trouver un fichier appelé 8139cp.c. Ce pilote de périphérique gère n'importe quelle carte réseau Ethernet utilisant un contrôleur Realtek de la série RTL-8139C+ qui, à l'époque, a été utilisé par de nombreux fabricants de cartes différentes, et vendu sous probablement plus de 100 marques différentes. Certaines versions ont été utilisées dans des cartes d'interface PCI interchangeables, tandis que d'autres ont été soudées directement sur les cartes mères. Mais toutes peuvent utiliser le même code du pilote développé initialement (comme c'est le cas pour la plupart du code d'interface réseau) par Donald Becker, comme il est mentionné dans la section de commentaire au début du fichier C. | Gardez s'il vous plaît à l'esprit que chaque bout de code d'un pilote dans ce répertoire ne s'occupe pas d'une marque particulière de matériel, mais plutôt des puces de contrôle utilisées dans ce matériel. Par exemple, dans le répertoire drivers/net/ethernet/realtek nous pouvons trouver un fichier appelé 8139cp.c. Ce pilote de périphérique gère n'importe quelle carte réseau Ethernet utilisant un contrôleur Realtek de la série RTL-8139C+ qui, à l'époque, a été utilisé par de nombreux fabricants de cartes différentes et vendu sous probablement plus de 100 marques différentes. Certaines versions ont été utilisées dans des cartes d'interface PCI interchangeables, tandis que d'autres ont été soudées directement sur les cartes mères. Mais toutes peuvent utiliser le même code du pilote développé initialement (comme c'est le cas pour la plupart du code d'interface réseau) par Donald Becker, comme il est mentionné dans la section de commentaire au début du fichier C. |
| |
| ====== 10 ====== | ====== 10 ====== |
| To initialize and use some of these devices, we will need not only a device driver - which is a program run by our computer's CPU and resident in its own memory - but also a piece of firmware - known as a “binary blob” - that must be loaded into the device's memory on initialization. These are not considered as part of the kernel itself.** | To initialize and use some of these devices, we will need not only a device driver - which is a program run by our computer's CPU and resident in its own memory - but also a piece of firmware - known as a “binary blob” - that must be loaded into the device's memory on initialization. These are not considered as part of the kernel itself.** |
| |
| Le répertoire firmware est l'autre endroit où nous allons trouver des morceaux de code qui ne sont pas écrits dans le langage de programmation C. Un ordinateur moderne peut à certains égards être considéré comme un réseau d'ordinateurs multiples : l'ordinateur principal délègue une partie du travail à d'autres systèmes : le système de traitement du son, la carte graphique, la carte réseau, un disque dur, une imprimante, etc., sont tous formés par de petits environnements informatiques, chacun contrôlé par un micro-contrôleur agissant comme un petit CPU sur son propre territoire. Le firmware est un concept qui vient de l'apparition de la mémoire non volatile, à la fois dans les appareils électroniques domestiques et dans les composants informatiques internes. Ces systèmes ont maintenant la capacité d'exécuter non seulement des programmes qui ont été écrits une fois pour toutes dans les puces ROM, « gravé dans la pierre » pour ainsi dire, mais peuvent également charger des programmes à la volée dans diverses formes de mémoire réinscriptible (EE-PROM ou mémoire « Flash »). Cette mémoire sur la carte fille contient des programmes sous forme binaire, qui ne sont pas destinés au CPU de l'ordinateur, mais au micro-contrôleur de chaque appareil ou composant. | Le répertoire firmware est l'autre endroit où nous allons trouver des morceaux de code qui ne sont pas écrits dans le langage de programmation C. Un ordinateur moderne peut à certains égards être considéré comme un réseau d'ordinateurs multiples : l'ordinateur principal délègue une partie du travail à d'autres systèmes : le système de traitement du son, la carte graphique, la carte réseau, un disque dur, une imprimante, etc., sont tous formés par de petits environnements informatiques, chacun contrôlé par un micro-contrôleur agissant comme un petit CPU à part entière. Le firmware est un concept qui vient de l'apparition de la mémoire non volatile, à la fois dans les appareils électroniques domestiques et dans les composants informatiques internes. Ces systèmes ont maintenant la capacité d'exécuter non seulement des programmes qui ont été écrits une fois pour toutes dans les puces ROM, « gravé dans la pierre » pour ainsi dire, mais peuvent également charger des programmes à la volée dans diverses formes de mémoire réinscriptible (EE-PROM ou mémoire « Flash »). Cette mémoire sur la carte fille contient des programmes sous forme binaire, qui ne sont pas destinés au CPU de l'ordinateur, mais au micro-contrôleur de chaque appareil ou composant. |
| |
| Pour initialiser et utiliser certains de ces dispositifs, nous aurons besoin non seulement d'un pilote de périphérique - qui est un programme géré par le CPU et résident dans notre ordinateur dans sa propre mémoire - mais aussi d'un morceau de firmware, connu comme un « blob binaire », qui doit être chargé dans la mémoire de l'appareil lors de l'initialisation. Ces derniers ne sont pas considérés comme faisant partie du noyau lui-même. | Pour initialiser et utiliser certains de ces dispositifs, nous aurons besoin non seulement d'un pilote de périphérique - qui est un programme géré par le CPU et résidant dans notre ordinateur dans sa propre mémoire - mais aussi d'un morceau de firmware, connu comme un « blob binaire », qui doit être chargé dans la mémoire du périphérique lors de l'initialisation. Ces derniers ne sont pas considérés comme faisant partie du noyau lui-même. |
| |
| ====== 11 ====== | ====== 11 ====== |
| **There has been some dispute about the nature of the firmware included with the Linux kernel. Some distributions, such as Ubuntu itself, have little qualms about including firmware that is not open-source or released under the GPL license. Their take is that the end-user wishes simply to have things work; since they have acquired the hardware, they must also have access to the software necessary to make it function. But there is also the contrary standpoint, proposed notably by Richard Stallman and adopted by distributions such as gNewSense, that argues that proprietary and non-open binary blobs may work, or not. They may work particularly well in some cases, and fail miserably in others – and for reasons unknown. Since nobody except the manufacturer has access to the source code, there is no way of assessing the firmware code, making it better, or adapting it to new needs. It is for this reason that the kernel.org project members take pains to trace the origins of binary blobs distributed with the kernel, as may be seen in file firmware/WHENCE. It is also for this reason that distributions such as Ubuntu or Linux Mint permit the installation of certain non open-source drivers, but only at the user's initiative and specifying clearly they come without any support from the distribution's team.** | **There has been some dispute about the nature of the firmware included with the Linux kernel. Some distributions, such as Ubuntu itself, have little qualms about including firmware that is not open-source or released under the GPL license. Their take is that the end-user wishes simply to have things work; since they have acquired the hardware, they must also have access to the software necessary to make it function. But there is also the contrary standpoint, proposed notably by Richard Stallman and adopted by distributions such as gNewSense, that argues that proprietary and non-open binary blobs may work, or not. They may work particularly well in some cases, and fail miserably in others – and for reasons unknown. Since nobody except the manufacturer has access to the source code, there is no way of assessing the firmware code, making it better, or adapting it to new needs. It is for this reason that the kernel.org project members take pains to trace the origins of binary blobs distributed with the kernel, as may be seen in file firmware/WHENCE. It is also for this reason that distributions such as Ubuntu or Linux Mint permit the installation of certain non open-source drivers, but only at the user's initiative and specifying clearly they come without any support from the distribution's team.** |
| |
| Il y a eu un différend à propos de la nature du firmware inclus dans le noyau Linux. Certaines distributions, comme Ubuntu, ont peu de scrupules à inclure des firmwares qui ne sont pas Open Source ou publiés sous la licence GPL. Leur point de vue est que l'utilisateur final souhaite simplement avoir des choses qui fonctionnent ; puisqu'ils ont acquis le matériel, ils doivent aussi avoir accès aux logiciels nécessaires pour le faire fonctionner. Mais il y a aussi le point de vue contraire, proposé notamment par Richard Stallman et adopté par des distributions comme gNewSense, qui soutient que les blobs binaires propriétaires et non ouverts peuvent fonctionner, ou pas. Ils peuvent fonctionner particulièrement bien dans certains cas, et échouer lamentablement dans d'autres, et pour des raisons inconnues. Comme personne à part le fabricant n'a accès au code source, il n'est pas possible d'évaluer le code du firmware, pour l'améliorer ou pour l'adapter aux nouveaux besoins. C'est pour cette raison que les membres du projet kernel.org prennent soin de retracer les origines des blobs binaires distribués avec le noyau, comme on le voit dans le fichier firmware/WHENCE. C'est aussi pour cette raison que les distributions comme Ubuntu ou Linux Mint permettent l'installation de certains pilotes non Open Source, mais seulement à l'initiative de l'utilisateur et en précisant clairement qu'ils sont livrés sans aucun soutien de l'équipe de la distribution. | Il y a eu un différend à propos de la nature du firmware inclus dans le noyau Linux. Certaines distributions, comme Ubuntu, ont peu de scrupules à inclure des firmwares qui ne sont pas Open Source ou publiés sous la licence GPL. Leur point de vue est que l'utilisateur final souhaite simplement avoir des choses qui fonctionnent ; puisqu'ils ont acquis le matériel, ils doivent aussi avoir accès aux logiciels nécessaires pour le faire fonctionner. Mais il y a aussi le point de vue contraire, proposé notamment par Richard Stallman et adopté par des distributions comme gNewSense, qui soutient que les blobs binaires propriétaires et non ouverts peuvent fonctionner, ou pas. Ils peuvent fonctionner particulièrement bien dans certains cas et échouer lamentablement dans d'autres, et pour des raisons inconnues. Comme personne à part le fabricant n'a accès au code source, il n'est pas possible d'évaluer le code du firmware, pour l'améliorer ou pour l'adapter aux nouveaux besoins. C'est pour cette raison que les membres du projet kernel.org prennent soin de retracer les origines des blobs binaires distribués avec le noyau, comme on le voit dans le fichier firmware/WHENCE. C'est aussi pour cette raison que les distributions comme Ubuntu ou Linux Mint permettent l'installation de certains pilotes non Open Source, mais seulement à l'initiative de l'utilisateur et en précisant clairement qu'ils sont livrés sans aucun soutien de l'équipe de la distribution. |
| |
| ====== 12 ====== | ====== 12 ====== |
| QUE NOUS FAUT-IL D'AUTRE ? | QUE NOUS FAUT-IL D'AUTRE ? |
| |
| Une fois que nous avons les sources du noyau décompressés sur notre disque, nous aurons besoin de plusieurs choses afin de compiler. Naturellement, nous aurons besoin du compilateur C, mais ce ne sera pas tout. | Une fois que les sources du noyau sont décompressés sur notre disque, nous aurons besoin de plusieurs choses pour pouvoir le compiler. Naturellement, nous aurons besoin du compilateur C, mais ce ne sera pas tout. |
| |
| Pour les lecteurs qui auraient besoin d'une explication rapide sur le processus de compilation, nous commençons par décrire certains concepts. Pour compiler un programme écrit dans un langage de programmation compilé, nous aurons tout d'abord besoin du programme lui-même, ou ce qu'on appelle le code source. C'est tout simplement un fichier texte qui contient les instructions de programme, même si l'extension a été changée en « .c » pour indiquer qu'il s'agit d'un fichier de code source C, et non pas d'un simple fichier contenant du texte. Nous allons maintenant poursuivre avec un court exemple d'un programme en C, contenu dans un fichier nommé « bonjour.c ». C'est peut-être l'exemple le plus connu de la programmation C, que presque tous les programmeurs auront vu à un moment donné : | Pour les lecteurs qui auraient besoin d'une explication rapide sur le processus de compilation, nous commençons par décrire certains concepts. Pour compiler un programme écrit dans un langage de programmation compilé, nous aurons tout d'abord besoin du programme lui-même, ou ce qu'on appelle le code source. C'est tout simplement un fichier texte qui contient les instructions de programme, même si l'extension a été changée en « .c » pour indiquer qu'il s'agit d'un fichier de code source C, et non pas d'un simple fichier contenant du texte. Nous allons maintenant poursuivre avec un court exemple d'un programme en C, contenu dans un fichier nommé « bonjour.c ». C'est peut-être l'exemple le plus connu de la programmation C, que presque tous les programmeurs auront vu à un moment donné : |
| Hello, world!** | Hello, world!** |
| |
| Les deux approches ont des avantages et des inconvénients. En utilisant les langages compilés, nous obtenons un fichier exécutable qui peut se dérouler très rapidement, et l'utilisateur final n'aura besoin d'accéder qu'à ce fichier unique. D'un autre côté, les langages interprétés donneront accès au code source à l'utilisateur final, qu'il ou elle pourra modifier et ajuster à ses besoins. Mais ils auront besoin d'avoir un interpréteur installé sur leur système pour ce langage particulier, et le résultat final s'exécutera un peu plus lentement. | Les deux approches ont des avantages et des inconvénients. En utilisant les langages compilés, nous obtenons un fichier exécutable qui peut se dérouler très rapidement, et l'utilisateur final n'aura besoin d'accéder qu'à ce fichier unique. En revanche, les langages interprétés donneront à l'utilisateur final accès au code source, qu'il pourra modifier et ajuster à ses besoins. Mais il faut qu'un interpréteur pour ce langage particulier soit installé sur leur système et le résultat final s'exécutera un peu plus lentement. |
| |
| Pour compiler notre programme de test « bonjour.c », en supposant que nous avons le compilateur C gcc installé sur notre système (sinon, nous aurons besoin d'installer le paquet "gcc"), nous pouvons saisir : | Pour compiler notre programme de test « bonjour.c », en supposant que nous avons le compilateur C gcc installé sur notre système (sinon, nous aurons besoin d'installer le paquet "gcc"), nous pouvons saisir : |
| $ cc bonjour.c -o bonjour | $ cc bonjour.c -o bonjour |
| |
| Ceci demande au compilateur C (« cc », vous comprenez ?) de compiler le fichier de code source « bonjour.c », et de produire le fichier exécutable « bonjour ». Notez que dans le monde UNIX et GNU/Linux, les fichiers exécutables n'ont pas besoin de l'extension « .exe ». Une fois que le fichier est compilé, l'exécutable résultant peut être exécuté par la commande : | Ceci demande au compilateur C (« cc », vous comprenez ?) de compiler le fichier de code source « bonjour.c », et de produire le fichier exécutable « bonjour ». Notez que dans le monde UNIX et GNU/Linux, les fichiers exécutables n'ont pas besoin de l'extension « .exe ». Une fois le fichier compilé, l'exécutable résultant peut être lancé par la commande : |
| |
| $ ./bonjour | $ ./bonjour |
| and the corresponding instructions from the makefile would be executed.** | and the corresponding instructions from the makefile would be executed.** |
| |
| Naturellement, les choses peuvent devenir un peu plus complexes quand un gros projet applicatif contient plusieurs centaines de fichiers C et en-têtes. Dans le cas du noyau Linux, tous ces fichiers ne sont pas toujours compilés selon l'architecture cible (Intel 32-bit, IA64, …) pour laquelle nous compilons. Pour simplifier les choses, on peut écrire un fichier contenant des instructions sur ce qu'il faut compiler, dans quel ordre, et avec quels paramètres de compilation. Ce makefile peut être considéré comme un modèle ou guide pour le processus de compilation. | Naturellement, les choses peuvent devenir un peu plus complexes quand un gros projet applicatif contient plusieurs centaines de fichiers C et en-têtes. Dans le cas du noyau Linux, tous ces fichiers ne sont pas toujours compilés, selon l'architecture cible (Intel 32-bit, IA64, …) pour laquelle nous compilons. Pour simplifier les choses, on peut écrire un fichier contenant des instructions sur ce qu'il faut compiler, dans quel ordre, et avec quels paramètres de compilation. Ce makefile peut être considéré comme un modèle ou guide pour le processus de compilation. |
| |
| Pour en revenir à notre exemple de programme, nous pourrions écrire le fichier « Makefile » avec le contenu suivant : | Pour en revenir à notre exemple de programme, nous pourrions écrire le fichier « Makefile » avec le contenu suivant : |
| cc bonjour.c -o bonjour | cc bonjour.c -o bonjour |
| |
| Maintenant, à chaque fois que nous souhaitons compiler le fichier, nous pourrions utiliser la commande make pour exécuter le contenu du fichier pour nous : | Maintenant, à chaque fois que nous souhaitons compiler le fichier, nous pourrions utiliser la commande make pour exécuter le contenu du fichier : |
| |
| $ make bonjour | $ make bonjour |
| qt4-default qt4-qmake** | qt4-default qt4-qmake** |
| |
| Comme vous vous en doutez, pour simplifier le processus de compilation du noyau Linux, à la fois le compilateur et l'environnement make de construction sont largement utilisés. C'est pourquoi nous aurons besoin d'avoir installé non seulement le compilateur C lui-même, mais aussi plusieurs programmes utilitaires : GNU make lui-même, un décompresseur bzip, etc. Les paquets suivants seront nécessaires à un certain moment dans le processus : | Comme vous vous en doutez, pour simplifier le processus de compilation du noyau Linux, le compilateur et l'environnement make de construction sont tous les deux largement utilisés. C'est pourquoi nous aurons besoin d'avoir installé non seulement le compilateur C lui-même, mais aussi plusieurs programmes utilitaires : GNU make lui-même, un décompresseur bzip, etc. Les paquets suivants seront nécessaires à un certain moment dans le processus : |
| |
| gcc binutils make bzip2 coreutils | gcc binutils make bzip2 coreutils |
| libgtk2.0-dev libglib2.0-dev libglade2-dev | libgtk2.0-dev libglib2.0-dev libglade2-dev |
| |
| Enfin, ma préférence pour configurer le noyau va à l'interfaces « curses » : | Enfin, ma préférence pour configurer le noyau va à l'interface « curses » : |
| |
| make menuconfig | make menuconfig |
| ncurses-dev | ncurses-dev |
| |
| Maintenant que nous avons tous les morceaux dont nous aurons besoin, dans la prochaine partie de cette série, nous allons passer en revue les options de compilation disponibles, et terminer en compilant notre premier noyau. | Maintenant que nous avons tous les morceaux dont nous aurons besoin, dans la prochaine partie de cette série, nous allons passer en revue les options de compilation disponibles et terminer en compilant notre premier noyau. |
| |
