12.4. Amorçage et configuration initiale d'un périphérique

Tous les événements du périphérique qui se produisent lors du processus d'amorçage avant l'exécution du démon udev sont perdus, car l'infrastructure qui gère ces événements réside dans le système de fichiers racine et n'est pas disponible à ce moment. Pour combler cette perte, le kernel fournit un fichier uevent pour chaque périphérique dans le système de fichiers sysfs. En écrivant add dans ce fichier, le kernel renvoie le même événement que celui perdu au cours de l'amorçage. Une simple boucle sur tous les fichiers uevent dans /sys redéclenche tous les événements pour créer les noeuds de périphérique et configurer le périphérique.

Par exemple, une souris USB présente lors de l'amorçage risque de ne pas être initialisée au début de la séquence d'amorçage, car le pilote n'est pas disponible à ce moment. L'événement lié à la découverte du périphérique a été perdu et n'a pas pu trouver de module kernel pour le périphérique. Au lieu de rechercher manuellement d'éventuels périphériques connectés, udev demande tous les événements de périphérique au kernel une fois que le système de fichiers racine est disponible. L'événement lié à la souris USB s'exécute alors à nouveau. Ensuite, il recherche le module kernel sur le système de fichiers racine monté et la souris USB peut être initialisée.

Du point de vue de l'espace utilisateur, il n'y a aucune différence visible entre une séquence de coldplug du périphérique et une découverte de périphérique au moment de l'exécution. Dans les deux cas, les mêmes règles sont utilisées pour la mise en correspondance et les mêmes programmes configurés sont exécutés.