| 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 17:07] – [10] auntiee | issue89:labo_linux_2 [2015/02/10 17:24] (Version actuelle) – [17] auntiee |
|---|
| **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. |
| |
