| Les deux révisions précédentesRévision précédente | |
| issue154:certifie_linux [2020/03/16 15:04] – d52fr | issue154:certifie_linux [2020/03/16 15:13] (Version actuelle) – andre_domenech |
|---|
| Celui-ci sera notre dernier regard aux prérequis d'une certification. La dernière fois, nous avons examiné des astuces pour la compilation du noyau. Cette fois-ci, ce sera la gestion du runtime du noyau et la résolution des problèmes. Le noyau de base Linux a parfois besoin d'un peu d'aide et c'est là où les LKM (loadable kernel modules ou modules chargeables du noyau) entrent en scène. Comme leur nom le suggère, ces modules sont chargés dans le noyau lorsque cela est nécessaire. Ainsi, quand le noyau démarre, ils n'accaparent pas des ressources mémoire, ils sont chargés en mémoire seulement quand ils sont appelés ou nécessaires. Ceci peut sembler idiot, mais, si le système n'a pas de port parallèle, pourquoi charger le module parport en mémoire ? | Celui-ci sera notre dernier regard aux prérequis d'une certification. La dernière fois, nous avons examiné des astuces pour la compilation du noyau. Cette fois-ci, ce sera la gestion du runtime du noyau et la résolution des problèmes. Le noyau de base Linux a parfois besoin d'un peu d'aide et c'est là où les LKM (loadable kernel modules ou modules chargeables du noyau) entrent en scène. Comme leur nom le suggère, ces modules sont chargés dans le noyau lorsque cela est nécessaire. Ainsi, quand le noyau démarre, ils n'accaparent pas des ressources mémoire, ils sont chargés en mémoire seulement quand ils sont appelés ou nécessaires. Ceci peut sembler idiot, mais, si le système n'a pas de port parallèle, pourquoi charger le module parport en mémoire ? |
| |
| Alors, quand est la dernière fois où vous avez regardé dans le dossier /lib/modules/ ? C'est là où les modules de votre noyau sont stockés. Ils sont spécifiques à la version du noyau, et vous devez donc rapidement vérifier cela avec uname. Connaissez-vous toujours bien les commutateurs pour uname ? Quel commutateur devriez-vous utiliser autre que -a ? Bien, -r. OK, c'est bon, vous avez suivi le cours avec attention. Il s'agit du répertoire où il faut aller, puis entrez dans le sous-répertoire nommé kernel (noyau) (si votre distribution est basée sur Red Hat). Si à quelque moment que ce soit vous vous sentez perdu, regardez l'article précédent sur la compilation du noyau, car vous devriez le savoir à ce stade. | Alors, quand est-ce la dernière fois où vous avez regardé dans le dossier /lib/modules/ ? C'est là où les modules de votre noyau sont stockés. Ils sont spécifiques à la version du noyau, et vous devez donc rapidement vérifier cela avec uname. Connaissez-vous toujours bien les commutateurs pour uname ? Quel commutateur devriez-vous utiliser autre que -a ? Bien, -r. OK, c'est bon, vous avez suivi le cours avec attention. Il s'agit du répertoire où il faut aller, puis entrez dans le sous-répertoire nommé kernel (noyau) (si votre distribution est basée sur Red Hat). Si à quelque moment que ce soit vous vous sentez perdu, regardez l'article précédent sur la compilation du noyau, car vous devriez le savoir à ce stade. |
| |
| **Now some people will say kernel objects. The extension is “.ko” after all. Just be aware of this, but do not get hung up on terminology. If you need to add a pre-compiled kernel object, you need to be aware of the dependencies. That is number 1. Your system also needs to know these things. Our lives are, however, simplified by a nifty tool named depmod (module dependencies). Now, if you look at the man page for depmod, under description, you will see: “These dependencies can get quite complex.” You can run depmod from your home directory, you do not need to be in the modules directory. Again be aware of the differences between Debian-based systems path and Red Hat-based systems path. If you run depmod on its own, you get no output. If you would like some, use the -v switch. Quickly do a cat on the modules.dep file. | **Now some people will say kernel objects. The extension is “.ko” after all. Just be aware of this, but do not get hung up on terminology. If you need to add a pre-compiled kernel object, you need to be aware of the dependencies. That is number 1. Your system also needs to know these things. Our lives are, however, simplified by a nifty tool named depmod (module dependencies). Now, if you look at the man page for depmod, under description, you will see: “These dependencies can get quite complex.” You can run depmod from your home directory, you do not need to be in the modules directory. Again be aware of the differences between Debian-based systems path and Red Hat-based systems path. If you run depmod on its own, you get no output. If you would like some, use the -v switch. Quickly do a cat on the modules.dep file. |
| You should see a whole bunch of .ko-files. This is all the detected modules on the system. You may need to scroll back a bit to see some kernel modules with a colon after them and more kernel modules after that. Like Windows services that depend on another service, this is how you find out which kernel module depends on which other kernel module. Anything BEFORE the colon depends on the listed modules AFTER the colon (very easy once you know it). Just like Windows services, multiple modules may depend on one module and vice-versa. You can do this on a modern release of Ubuntu, you do not need to be in your CentOS 5 VM. However, in your Ubuntu workstation, you will not find the “map” files mentioned. You will only find them in your CentOS 5 VM. Each ”map” file (eg. modules.serio.map) will map out the addresses to certain interfaces. Go ahead and cat module.serio.map, and peruse the output. So when you plug in a device, the kernel then can determine which device driver to load. You can think of these as lookup tables. That should demystify why the Red Hat systems have map files in the kernel folder. When you actually write kernel modules, you will have to include a header linux/module.h and linux/kernel.h, as well as macros, for things like licensing. All these are taken into account when you try to add a module.** | You should see a whole bunch of .ko-files. This is all the detected modules on the system. You may need to scroll back a bit to see some kernel modules with a colon after them and more kernel modules after that. Like Windows services that depend on another service, this is how you find out which kernel module depends on which other kernel module. Anything BEFORE the colon depends on the listed modules AFTER the colon (very easy once you know it). Just like Windows services, multiple modules may depend on one module and vice-versa. You can do this on a modern release of Ubuntu, you do not need to be in your CentOS 5 VM. However, in your Ubuntu workstation, you will not find the “map” files mentioned. You will only find them in your CentOS 5 VM. Each ”map” file (eg. modules.serio.map) will map out the addresses to certain interfaces. Go ahead and cat module.serio.map, and peruse the output. So when you plug in a device, the kernel then can determine which device driver to load. You can think of these as lookup tables. That should demystify why the Red Hat systems have map files in the kernel folder. When you actually write kernel modules, you will have to include a header linux/module.h and linux/kernel.h, as well as macros, for things like licensing. All these are taken into account when you try to add a module.** |
| |
| Certaines personnes diront kernel objects. Après tout, l'extension est « .ko ». Il suffit de le savoir, mais ne vous attardez pas sur la terminologie. Si vous devez ajouter un kernel object pré-compilé, vous devrez être conscient des dépendances. C'est le numéro 1. Votre système doit connaître ces choses aussi. Toutefois, notre vie est simplifié par un outil chouette, nommé depmod (les dépendances du module). Si vous regardez la page man pour depmod, dans la section description, vous verrez : « Ces dépendances peuvent devenir très complexes. » Vous pouvez lancer depmod à partir de votre répertoire personnel ; nul besoin d'être dans le répertoire des modules. À nouveau, il faut être conscient des différences de chemin entre les systèmes basés sur Debian et ceux basés sur Red Hat. Si vous exécutez depmod tout seul, il n'y a pas de résultat. Si vous en voulez, utilisez le commutateur -v. Et faites un cat rapide sur le fichier modules.dep. | Certaines personnes diront kernel objects. Après tout, l'extension est « .ko ». Il suffit de le savoir, mais ne vous attardez pas sur la terminologie. Si vous devez ajouter un kernel object pré-compilé, vous devrez être conscient des dépendances. C'est le numéro 1. Votre système doit connaître ces choses aussi. Toutefois, notre vie est simplifiée par un outil chouette, nommé depmod (les dépendances du module). Si vous regardez la page man pour depmod, dans la section description, vous verrez : « Ces dépendances peuvent devenir très complexes. » Vous pouvez lancer depmod à partir de votre répertoire personnel ; nul besoin d'être dans le répertoire des modules. À nouveau, il faut être conscient des différences de chemin entre les systèmes basés sur Debian et ceux basés sur Red Hat. Si vous exécutez depmod tout seul, il n'y a pas de résultat. Si vous en voulez, utilisez le commutateur -v. Et faites un cat rapide sur le fichier modules.dep. |
| |
| Vous devriez voir une foule de fichiers .ko. Ce sont tous les modules détectés sur le système. Vous devrez sans doute remonter un peu pour voir quelques modules du noyau suivi d'un deux-points et d'autres modules du noyau après cela. Comme pour les services de Windows qui dépendent d'un autre service, c'est comme cela que vous trouvez quel module du noyau dépend de quel autre module. Tout ce qui s'affiche AVANT les deux-points dépend des modules listés APRÈS celui-ci (c'est très facile une fois que vous le savez). Tout comme pour les services Windows, de multiples modules peuvent dépendre d'un seul module, et vice versa. Vous pouvez faire cela sur une version récente d'Ubuntu ; pas besoin d'être dans votre machine virtuelle avec CentOS 5. Cependant, dans la station de travail d'Ubuntu, vous ne trouverez pas les fichiers « map » mentionnés. Vous ne les trouverez que dans votre VM avec CentOS 5. Chaque fichier « map » (par exemple modules.serio.map) mappera les adresses vers certaines interfaces. Allez-y, faites un cat module.serio.map et étudiez le résultat. Ainsi, quand vous branchez un appareil, le noyau peut déterminer quel pilote charger. Pensez-y comme des tables à consulter. Cela devrait vous dire pourquoi les systèmes Red Hat mettent les fichiers map dans le dossier du noyau. Quand vous écrirez en fait des modules pour le noyau, vous devrez inclure une en-tête linux/module.h et linux/kernel.h ainsi que des macros pour des trucs comme les licences. Toutes ces choses sont prises en compte quand vous essayez d'ajouter un module. | Vous devriez voir une foule de fichiers .ko. Ce sont tous les modules détectés sur le système. Vous devrez sans doute remonter un peu pour voir quelques modules du noyau suivi d'un deux-points et d'autres modules du noyau après cela. Comme pour les services de Windows qui dépendent d'un autre service, c'est comme cela que vous trouvez quel module du noyau dépend de quel autre module. Tout ce qui s'affiche AVANT les deux-points dépend des modules listés APRÈS celui-ci (c'est très facile une fois que vous le savez). Tout comme pour les services Windows, de multiples modules peuvent dépendre d'un seul module, et vice versa. Vous pouvez faire cela sur une version récente d'Ubuntu ; pas besoin d'être dans votre machine virtuelle avec CentOS 5. Cependant, dans la station de travail d'Ubuntu, vous ne trouverez pas les fichiers « map » mentionnés. Vous ne les trouverez que dans votre VM avec CentOS 5. Chaque fichier « map » (par exemple modules.serio.map) mappera les adresses vers certaines interfaces. Allez-y, faites un cat module.serio.map et étudiez le résultat. Ainsi, quand vous branchez un appareil, le noyau peut déterminer quel pilote charger. Pensez-y comme des tables à consulter. Cela devrait vous dire pourquoi les systèmes Red Hat mettent les fichiers map dans le dossier du noyau. Quand vous écrirez en fait des modules pour le noyau, vous devrez inclure une en-tête linux/module.h et linux/kernel.h ainsi que des macros pour des trucs comme les licences. Toutes ces choses sont prises en compte quand vous essayez d'ajouter un module. |
| « filename » vous donne le chemin entier ! Le macro de la licence, que j'ai mentionné plus tôt, devrait venir ensuite, vous détaillant ce que vous pouvez faire avec le dit module. Cela est très utile quand vous travaillez avec, disons, une distribution uniquement libre. Notez les « depends », car c'est le module dont il dépendrait ; aussi, vous devrez peut-être installer un autre module avant celui-ci, s'il n'est pas déjà installé. Ainsi, si vous voulez ajouter le module psmouse, vous devrez copier le chemin « file name » à partir de modinfo (le fichier.ko). | « filename » vous donne le chemin entier ! Le macro de la licence, que j'ai mentionné plus tôt, devrait venir ensuite, vous détaillant ce que vous pouvez faire avec le dit module. Cela est très utile quand vous travaillez avec, disons, une distribution uniquement libre. Notez les « depends », car c'est le module dont il dépendrait ; aussi, vous devrez peut-être installer un autre module avant celui-ci, s'il n'est pas déjà installé. Ainsi, si vous voulez ajouter le module psmouse, vous devrez copier le chemin « file name » à partir de modinfo (le fichier.ko). |
| |
| Sachez que modinfo et modprobe fonctionnent de la même façon. c'est pourquoi je vous conseille de penser à modprobe comme étant celui qui est intelligent. Si vous ne pouvez pas bien distinguer les deux, mettez une perruque blonde sur insmod [Ndt : serait-ce une remarque sexiste ?!]. Une commande amusante est de taper modprobe sams_brain (le cerveau de Sam, si Sam portait le bonnet d'âne dans votre classe) et vous devriez avoir comme résultat : « module sams_brain not found ». Allez-y, ajoutez et enlevez ce fichier bidon, pour que vous puissiez vous accoutumer à la façon de faire les choses. Ajoutez le fichier bidon avec insmod aussi bien qu'avec modprobe, puis l'enlevez avec rmmod et avec modprobe. (Il faut connaître les deux façons de faire pour l'examen LPIC-201.) | Sachez que modinfo et modprobe fonctionnent de la même façon. c'est pourquoi je vous conseille de penser à modprobe comme étant celui qui est intelligent. Si vous ne pouvez pas bien distinguer les deux, mettez une perruque blonde sur insmod [Ndt : serait-ce une remarque sexiste ?!]. Une commande amusante est de taper modprobe sams_brain (le cerveau de Sam, si Sam portait le bonnet d'âne dans votre classe) et vous devriez avoir comme résultat : « module sams_brain not found ». Allez-y, ajoutez et enlevez ce fichier bidon, pour que vous puissiez vous accoutumer à la façon de faire les choses. Ajoutez le fichier bidon avec insmod aussi bien qu'avec modprobe, puis enlevez-le avec rmmod et avec modprobe. (Il faut connaître les deux façons de faire pour l'examen LPIC-201.) |
| |
| **One thing I skipped was the”parm” that you see in modinfo. This is actually parameters that you can specify when loading a module. Now one of the tricks , if you roll your own kernel, is to tweak some of these values, like resolution: 800 , for instance. Which you can use to match the dpi of your mouse. However, this is not a constant value, as after the next boot, the parameters are gone. You need to make these constant / permanent in another way. Sometimes you need to blacklist a module, like Nvidia, for instance. You will find those configuration files in /etc/modprobe.d/. If you look here, inside your Ubuntu desktop PC, you should see quite a few blacklist files. Feel free to “cat” out these files. Know that blacklist files take precedence. | **One thing I skipped was the”parm” that you see in modinfo. This is actually parameters that you can specify when loading a module. Now one of the tricks , if you roll your own kernel, is to tweak some of these values, like resolution: 800 , for instance. Which you can use to match the dpi of your mouse. However, this is not a constant value, as after the next boot, the parameters are gone. You need to make these constant / permanent in another way. Sometimes you need to blacklist a module, like Nvidia, for instance. You will find those configuration files in /etc/modprobe.d/. If you look here, inside your Ubuntu desktop PC, you should see quite a few blacklist files. Feel free to “cat” out these files. Know that blacklist files take precedence. |
| There is obviously a lot more here, but unless there is interest, next month we will start something new.** | There is obviously a lot more here, but unless there is interest, next month we will start something new.** |
| |
| Une chose que j'ai sautée était le « parm » visible dans modinfo. Il s'agit en fait des paramètres que vous pouvez spécifier quand vous chargez un module. Un des trucs que vous pouvez faire, si vous compilez votre propre noyau, est l'ajustement de quelques-unes de ces valeurs, comme la résolution : 800, par exemple, que vous pouvez faire correspondre aux dpi de votre souris. Cependant, ce n'est pas une valeur constante, car, après le prochain démarrage, les paramètres auront disparu. Ils vous les rend constants/permanents d'une autre façon. Vous devez parfois ajouter un module à la liste noire, notamment Nvidia. Vous trouverez ces fichiers de configuration dans /etc/modprobe.d/. Si vous regardez dedans, vous verrez sans doute pas mal de fichiers sur la liste noire à l'intérieur de votre ordinateur de bureau sous Ubuntu. N'hésitez pas à lancer « cat » pour ces fichiers et sachez que les fichiers sur la liste noire sont passés en priorité. | Une chose que j'ai sautée était le « parm » visible dans modinfo. Il s'agit en fait des paramètres que vous pouvez spécifier quand vous chargez un module. Un des trucs que vous pouvez faire, si vous compilez votre propre noyau, est l'ajustement de quelques-unes de ces valeurs, comme la résolution : 800, par exemple, que vous pouvez faire correspondre aux dpi de votre souris. Cependant, ce n'est pas une valeur constante, car, après le prochain démarrage, les paramètres auront disparu. Il vous les rend constants/permanents d'une autre façon. Vous devez parfois ajouter un module à la liste noire, notamment Nvidia. Vous trouverez ces fichiers de configuration dans /etc/modprobe.d/. Si vous regardez dedans, vous verrez sans doute pas mal de fichiers sur la liste noire à l'intérieur de votre ordinateur de bureau sous Ubuntu. N'hésitez pas à lancer « cat » pour ces fichiers et sachez que les fichiers sur la liste noire sont passés en priorité. |
| |
| IL y a, bien évidemment, beaucoup plus à ce sujet, mais, à moins que de l'intérêt ne se soit manifesté, le mois prochain, je commencerai quelque chose de nouveau. | IL y a, bien évidemment, beaucoup plus à ce sujet, mais, à moins que de l'intérêt ne se soit manifesté, le mois prochain, je commencerai quelque chose de nouveau. |
