UDEV – HAL – SMART - Tutoriels et Cours

I►Dans cet article, nous abordons la gestion des périphériques sous Linux :

I►Chapitre I : UDEV

UDEV apparu avec le noyau 2.6 (il a remplacé devfs). Il gère directement les entrées des périphériques en les créant dynamiquement dans le répertoire /dev/.
=> Les entrées de ces devices peuvent être renommées, ceci évite le problème du nommage automatique des disques séries par exemple.
=> Les applications accèdent aux périphériques via des fichiers placés sous /dev/ (par exemple /dev/sda).
UDEV dialogue avec HOTPLUG qui s’éxécute en mode noyau …

UDEV exploite directement les informations contenues dans /sys/ => SYSFS (pseudo file system comme /proc)
On branche une clé, dmesg nous donne l’information de nom qu’a créé UDEV
On peut faire un ls -l /dev/sdb

Le Pseudo FileSystem SYSFS regroupe toutes les informations des périphériques transmises par le noyau :

device : infos du périphérique
class : fournit un ensembel de fonctions communes aux périphériques
bus : géré par un controleur de bus relie les périphériques entre eux
driver : pilote (logiciel) inclus dynamiquement ou statiquement dans le noyau

Il prend en charge le branchement à chaud des périphériques, associe les pilotes aux périphériques, ….
cat /block/sda/size donne la taille du device sda en secteurs.

=> La commande systool (sysfsutils) montre les éléments de sysfs

systool -b scsi – v : donne les infos du bus scsi
systool -b usb -v : donne les infos du bus usb
systool : liste tout

La gestion du périphérique sous Linux se décompose ainsi :

1 driver(pilote) de périphérique est intégéré de manière statique ou dynamique en tant que module => Voir TP plus loin comment compiler un module …
configuration de ce pilote
1 fichier créé par udev dans /dev/…

La commande udevadm donne un maximum d’informations sur les périphériques, elle est capable de lire l’immense arborescence de /sys/

Exemple : on branche une clé USB, UDEV crée son fichier sous /dev/sde

Cette commande nous donne une foule d’informations sur le périphérique …

=> block est un sous-répertoire de /sys/

UDEV est capable de gérer les devices grâce à un ensemble de règles : les règles locales et celles du système.

/lib/udev/rules.d/ contient les règles du sytème que l’on ne peut pas modifier
notamment 40-redhat.rules

/etc/udev/rules.d/ contient les règles locales que l’on peut modifier
exemple : nous souhaitons qu’une clé soit crée avec un nom différent de sdx ou qu’elle ait un lien ou qu’elle éxécute un script shell, lorsque le système notifie l’événement de son interruption matérielle …
Nous créons une règle 20-perso.rules :

Lorsqu’on branche la clé, le lien se crée et on pourra monter la clé avec ce nom là ! le script cle.sh s’éxécute !

udevadm test /block/sde : liste toutes les règles qui seront invoquées lors du débranchement de la clé.

udevadm monitor –environment : monitorise toutes les informations des périphériques …

———————————————————————————————-
=> Chapitre II – HAL : Hardware Abstraction Layer
———————————————————————————————-

HAL permet aux systèmes et applications graphiques de découvrir et d’utiliser les périphériques : clé USB, cd …
HAL récupère les informations des périphériques grâce à UDEV et fournit aux applications une interface de communication D-BUS
=> D-Bus permet aux applications ou aux programmes de communiquer entre eux.

Les programmes peuvent s’enregistrer auprès de D-Bus qui offre leurs services aux autres programmes et leur permet de savoir quels services sont disponibles et d’être informés des événements signalés ! (ex: le branchement d’une clé..) => les événements avec UPSTART et SYSTEMD…

HAL identifie les périphériques en notation OBJET UDI Uniwue device identifier

lshal -t : affiche l’arborescene des périphériques
lshal -s : affiche la liste de spériphériques
lshal -m : pour monitoriser HAL

Les fichiers de conf : /etc/hal/

———————————————————————————————-
=> Chapitre III – La technologie SMART
———————————————————————————————-

SMART : Self Monitoring Analysis and Reporting Technology :
Cette technologie permet de surveiller les disques durs et d’anticiper les éventuelles pannes …
SMART peur surveiller la fiabilité des disques durs.
SMART est intégré dans la plupart des disques durs :

IDE : disque parrallèle
ATA : disque série
SCSI :disque série rapide
SSD : Solid State Drive :
Les disques SSD permettent le stockage sur de la mémoire Flash
Ils sont plus solides, moins bruyants et beaucoup plus performants en termes d’accès aux données que les autres disques
Les temps de lecture et écriture sont redoutables !

La commande smartctl permet d’exploiter les données SMART :

smartctl -i /dev/sda : permet de voir si le matériel est compatible SMART
smartctl -a /dev/sda : affiche un maximum d’infos et donne le résultat des tests effectués précédemment
smartctl -t short /dev/sda : démarre un test court
smartctl -l error /dev/sda : détecte les éventuelles erreurs d’un disque

———————————————————————————————-
=> Chapitre IV – Comment compiler un module pour un périphérique
———————————————————————————————-

Nous allons voir comment compiler un module et le charger manuellement ou dynamiquement …

Tout d’abord, il faut télécharger les sources du module :
https://www.mb-creation-web.fr/linux-tools/hello_printk.tar.gz

Pour pouvoir faire le make, il est impératif d’avoir les sources du kernel dans arborescence /usr/src/kernels/
On peut faire un yum install kernel-devel (RH/CentOs) ou apt-get install linux-image-<version> (Debian)
Astuce renommer le répertoire des sources du kernel avec la version de votre noyau : uname -r

Une fois le module compile, modprobe ne fonctionnera pas car hello_print.ko n’est pas déployé dans l’arborescence des modules /lib/modules/2.6…/

On pourra toujours l’insérer de force avec insmod hello_printk.ko et le supprimer avec rmmod hello_printk. Ces deux commandes ne se soucient pas de la table des symboles du noyau et ne vont pas consulté les dépendances des modules 🙁

=> Le fichier /lib/modules/2.6……./modules.dep contient la liste des dépendances de chargement de chaque module. Ce fichier est lu à chaque fois que l’on utilise modprobe !

Il vaut mieux donc placer notre hello_printk.ko sous /lib/modules/2.6…./kernel/drivers/misc/ et éxécuter depmod -a qui va recréer le fichier modules.dep

Dernière astuce, pour charger automatiquement le module en mémoire au démarrage de la machine on va éditer sous Debian le fichier /etc/modules et sous RH/CentOs on placera un fichier sous /etc/sysconfig/modules/
=> Car en effet dans /etc/rc.sysinit (lu au démarrage de la machine), tous les scripts présents sous /etc/sysconfig/modules sont éxécutés

Que fait ce driver au final 🙂 ?

Et bien lorsqu’on le charge en mémoire (insmod ou modprobe) dans dmesg on verra Hello World et lorsqu’on le décharge (rmmod ou modprobe -r) dans dmesg on verra GoodBye …

Tout simplement … lisez le fichier C d’origine (hello_printk.c présent dans l’archive tar)

=> Les fichiers de configuration des modules se trouvent sous :

/etc/modprobe.conf ou /etc/modprobe.d/xxxxx.conf
=> le fichier blacklist.conf empêche le chargement du module au démarrage
il faut faire un update-initramfs -u après avoir éditer ce fichier
=> Tous les autres fichiers donnent les alias (correspondance en devices et modules)

Michel BOCCIOLESI