Ceci est une ancienne révision du document !
SINCE THERE HAS BEEN NO FEEDBACK OR INTEREST IN THIS SERIES, I HAVE DECIDED TO RETIRE IT. This will be our last look into the certification prerequisites. Last time, we looked at tips for compiling a kernel. This time around it is kernel run-time management and troubleshooting. The base Linux kernel sometimes needs a little help, that is where loadable kernel modules come in. (LKM). Just like the name suggests, these modules are loaded into the kernel as necessary. So they do not take up any memory when the kernel starts, they get loaded into memory only when called or needed. This may sound silly, but if the system does not have a parallel port, why load the parport module into memory? So, when last have you looked in the /lib/modules/ directory? That is where your kernel modules are stored. They are based on the kernel version, so quickly check it with uname. Are you still fresh on the switches for uname? Which switch would you use other than -a ? Yep, -r. OK great, you have been paying attention. Well that is the directory you need to navigate to and enter its sub-directory named kernel (if you are on a Red Hat based distribution). If at any time you feel lost, refer to the previous article on kernel compilation, as you should know this by now.
PUISQU'IL N'Y A JAMAIS EU NI RETOURS NI INTÉRÊT DANS CETTE SÉRIE, J'AI DÉCIDÉ DE L'ABANDONNER.
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 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 version spécifique, et vous devez donc rapidement cela avec uname. Connaissez-vous toujours bien les commutateurs pour uname ? Quel commutateur devriez-vous utiliser autre que -a ? Ouais, -r. OK, c'est bon, vous avez suivi le cours avec attention. Il s'agit du répertoire où il faut aller, puis d'entrer 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. 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 voudrez, 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 devriez sans doute remonter un peu pour voir quelques modules du noyau suivi d'un deux-points et plus de 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 sur quel autre module. Tout ce qui s'affiche AVANT les deux-points dépend sur les 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 dossieur 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.
So how do we add or remove modules then? Why would we even want to remove any loadable kernel modules? Well, for one, it frees up memory. IOT is the current buzzword and usually IOT devices are spec’ed very low. But before we start removing modules, how about we look at them first? To list the currently installed modules, we remember back to LPIC level one and use the lsmod command. When you run the lsmod command, translate “used by” to “dependent on”, in your mind. That way you will know if a module can be removed safely or other modules or processes depend on it. It is a good idea to always check with lsmod, BEFORE using rmmod. This is especially true when using the -f switch, not that I ever advise you to use the -f switch. Now, if you have read the chapter in the book, you will know we have lsmod, rmmod and insmod. (yes, I know, but we are getting to it). Think of insmod as the dumb one. When you use insmod, you need the full path of where the particular module is. So we also need to know about modprobe and modinfo. Instead of telling you to peruse the manpages on this, I am going to suggest that you try bropages or cheat or even TL;DR. The modinfo command will list what you need to know about that particular module.
Alors comment ajouter ou enlever des modles ? De toute façon, pourquoi voudrions-nous enlever quelque module chargeable du noyau qui soit ? Une raison est que cela libère de la mémoire. Le mot à la mode est actuellement IOT (Internet of Things, ou Objets connectés) et généralement les dispositifs IOT ont des spécifications minimes. Mais avant de commencer à enlever des modules, regardons-les d'abord, non ? Pour lister les modules actuellement installés, nous nous souvenons du LPIC niveau un et utilisons la commande lsmod. Quand vous lancez la commande lsmod, traduisez « used by » par « dependent on » dans votre tête. Comme cela, vous saurez si un module peut être enlevé en toute sécurité ou si d'autres modules ou processus en sont dépendants. C'est une bonne idée de vérifier toujours avec lsmod, AVANT d'utiliser rmmod.
C'est particulièrement vrai quand vous utilisez le commutateur -f ; mais je ne vous conseille jamais d'utiliser le commutateur -f. Bon, si vous avez lu le chapitre du livre, vous saurez que nous avons lsmod, rmmod et insmod. (Oui, je sais, mais nous y venons.) Pensez à insmod comme celui qui est bête. Quand vous utilisez insmod, vous devez connaître le chemin complet vers l'emplacement du module concerné. Ainsi, nous devons connaître modprobe et modinfo. Au lieu de vous dire de bien lire les pages man dessus, je vais suggérer que vous essayez bropages ou cheat ou même TL;DR. La commande modinfo vous donnera tout ce qu'il faut savoir sur tout module précis.
For example type: modinfo psmouse The “filename” lists the full path for your pleasure. That license macro I mentioned earlier should be next, telling you what you can do with said module. This is very handy when you work with say, a libre-only distribution. Notice “depends”, as this is the module it would depend on, so you may need to install a module before this one, if it was not installed. So if you wanted to add the psmouse module, you would need to copy the “filename” path from modinfo (the .ko-file). Know that modinfo and modprobe work the same way. That’s why I say you should think of modprobe as the smart one. Put a blonde wig on insmod, if you cannot remember which is which. A fun command is to type: modprobe sams_brain (If Sam was the slow kid in class) and you should get back: “module sams_brain not found.” Go ahead and add and remove the dummy file, so you can get used to the way of doing things. Add the dummy file with insmod as well as modprobe, then remove it with rmmod and with modprobe. (You need to know both ways for the LPIC-201 exam).
Par exemple, tapez : modinfo psmouse
« filename » vous donne le chemin entier ! Le macro 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 utiles quand vous travaillez avec, dison une distribution uniquement libre. Notez les « depends », car c'est le module dont il dépendrait ; aussi vous devriez 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 consseil de pensez à 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 tapez 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 ».
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.
If you would like to jump ahead, or test your skills at an LPI exam, do a test paper here: https://www.itexams.com/exam/117-201 (These were once valid LPI questions and will ease you into the format.) • The new exam number is 201-400, and 117-201 was the old one. • The site does require signing up, but sign up with temporary email – not your real email. • DO NOT learn these questions parrot fashion, as they are probably not real exam questions.
Let us know how you did – good or bad, it does not matter. ‘Good’ means you are ready to write and confident in your skills. ‘Bad’ means you will be learning new stuff!! Yay! There is no downside here. If you do not know why an answer is the way it is, contact us.
As always, comments or corrections to: misc@fullcirclemagazine.org