[Résolu] Gestion du matériel par le kernel

naguam · 18-11-2018 22:20:08

Je me pose une question à laquelle je n'ai pas vraiment trouvé de réponse.
Car à chaque recherche sur différents moteurs de recherche, je tombais sur les soucis des gens pour faire fonctionner leur matériel.

Comment le kernel gère le matériel non supporté ? (donc IDs non répertoriés, car il me semble que le kernel détecte les périphériques internes et externe par leur ID ce qui permet de différencier une souris d'une clef usb ou un gpu d'une carte son)

Plus précisément, si par exemple j'ai un lecteur d’empreintes digitale sur un laptop, non supporté par le kernel, le détecte-t-il dans lspci -v ou lsusb...etc(mais pas de kernel module load), ou sinon si même pas détecté dans lspci ou lsusb, si le kernel le liste quelque part dans /sys/ ou /proc/ sous forme d'adresse car ID non reconnue.

Ensuite, si reconnu ou pas, est-ce que le périphérique est éteint ou pas (par exemple si il ne fonctionne pas, je veux pas qu'il consomme de l'électricité et le laisser de côtés).

Bref mon but est de savoir comment ça fonctionne la gestion du matos par le kernel. (en détail, mais et dans un maximum de cas de figure et pas seulement ceux que j'ai cité svp

)

(je ne suis pas assez barbu pour comprendre des sujet aussi complexes dans la doc du kernel)

PS: je suis aussi curieux de savoir (si ça prend pas trop de temps) comment l'initramfs fait pour être généré automatiquement (dracut ou update-initramfs) et pourquoi certaines architectures ne le nécessitent pas grâce aux .dtb et à uboot (si utilisé qui n'est je crois pas qu'un bootloader) notamment qui je crois donne au kernel les infos.

Voilà

merci

Dernière modification par naguam (11-09-2019 13:22:34)

naguam · 19-11-2018 21:41:16

Petit up

LaFouine · 20-11-2018 08:20:26

naguam a écrit :

Comment le kernel gère le matériel non supporté ?)

Vu la quantiter de matériel , c'est pas possible de tous les gérer si en plus il sont fermer .... pour ce qui est du courant électrique pour une approche disons un peux "scientifique" il te faut mesurer a la prise électrique plutôt que de te fier a ce qui est dans les logiciel. tu regarde ce que ça consomme vraiment. il existe des appareil pas trop cher pour le faire.

dans la logique si un périphérique est allumer par défaut et qu'il n'y a rien pour l’éteindre bah sa va tourner donc c'est pas linux qui en est responsable mai bien le constructeur puisque c 'est lui qui défini les variables par défauts. et bien souvent des driver fermer.

naguam · 22-11-2018 07:23:02

Cela ne me répond pas vraiment à ma question, mon but est de savoir comment le kernel gère le matériel supporté mais surtout le non supporté.
Je suis curieux du fonctionnement du kernel, oui je pourrais tester à la prise mais ce n'est pas mon but,.
Mon but est de savoir si le kernel a des "mécanismes" pour ce genre de cas de figure et comment ils fonctionnent.

Mais merci d'avoir pris le temps de me répondre

.

Dernière modification par naguam (22-11-2018 07:23:48)

naguam · 24-11-2018 21:25:21

Un dernier petit up au cas où raleur passerai par là et s'y connaîtrait

anonyme · 27-11-2018 07:18:46

Bonjour
Pour désactiver le matériel , c'est a partir du bios uniquement (si matériel intégré sinon le retirer de la machine , si une carte ).
ps: si pas d'options dans le bios pour la désactivation , le matériel consommera . je suppose que comme sur windows il est possible de désactiver le matériel (il ne consommera pas de ressources du système , mais il restera alimenté )

Pour le noyau , si les ressources ne sont pas affectées par celui ci (a l'init ) , le matériel ne fonctionnera pas ( IRQ , ressources mémoires etc ..... ).

ça répond pas a ta question mais bon a savoir (ps: au niveau de l'énergie ça reste assez faible , consommée ).

Si un jour tu a l'occasion d'avoir de quoi mesurer la consommation a la prise de courant , tu verra que sous le bios (sans OS chargé), la consommation du PC est importante (environ la consommation en charge de la machine sous l'OS).

j' utilisai cette information pour connaître la conso du PC cpu a 100% (avec le temps passé pour effectuer une tache , cpu a 100% , j'avais le ratio consommation/puissance machine).
L' idéal c'est d'avoir le moins de consommation pour une puissance maximum de la machine.
A cela tu dois ajouter le gpu (deuxième gros consommateur d'énergie ).

le mieux est d'avoir tout le matériel bien géré , désactivé ce qui n'est pas utilisé par le bios (si possible) .
Pour GNU Linux si quelqu'un veut te répondre comment désactiver le matériel (si c'est possible ) , avoir des choses mal gérées ça peu apporter des bugs.
nota : sur windows dans => le menu matériel => sélectionner => désactiver. (dans ce cas l'OS n' affectera pas de ressources a ce matériel (ignoré) ), mais il sera alimenté quand même ).

PS: sur des machines en PXE (en client léger) , je fonctionnais avec uniquement : "carte mère , cpu , mémoire (128 ou 256 Mo) , carte réseau PXE" (tous le reste est soit retiré , soit désactivé dans le bios)
j'avais par exemple 30 intel pentium "P3" (comme client léger ) et un serveur Linux pour gérer le serveur PXE (en intel pentium P4) sur des hub 10Mb

. (ceci dans les années 2005 ).

A l'époque il y avais très peu de matériel intégré sur la carte mère (pas d'audio , pas de réseau etc ............).
sinon les clients léger , pas d' écran , pas de clavier ,pas de souris , pas de cdrom etc ..........
Mais je me suis jamais posé la question comme tu a fait (au niveau de l'OS ) sous GNU Linux

Possible ou pas le sujet est intéressant

(dans mon exemple ci dessus les clients léger récupéré un noyau minimal sur le serveur mais c'est pas moi qui l'ai fait

(un dérivé de Knoppix si je me trompe pas) )
ps: pour du calcul partagé (pas un calcul unique partagé , mais autant que de client léger , le but était de réduire la consommation le plus possible et de ne sauvegarder les résultats que sur le serveur (lui ondulé ) ).
=> https://fr.wikipedia.org/wiki/Knoppix

Ce qui m'a fait rester sur windows jusqu' en 2014 , c'est les jeux

remarque: ça va mettre un peu d' ambiance sur ta demande

Dernière modification par anonyme (27-11-2018 07:24:14)

phlinux · 27-11-2018 14:12:13

Bjr,
Tu cherches ce genre d'info ?
Démarrage du noyau Linux
Le processus de démarrage d'un système Linux

Dernière modification par phlinux (27-11-2018 14:17:00)

MicP · 27-11-2018 16:21:23

Bonjour

Voir aussi :

fr.wikipedia.org : ACPI

en.wikipedia.org : ACPI

fr.wikipedia.org : APM

en.wikipedia.org : APM

"Parfois", un composant matériel ou un périphérique n'a pas été conçu pour répondre de façon standardisé
à certains messages qui permettraient (au BIOS, EFI, noyau, logiciels, etc.) de communiquer avec lui
et/ou le fabricant de ce matériel ne veux fournir qu'à certains les informations qui permettraient d'utiliser toutes ses fonctionnalités.

"Parfois" aussi, un fichier "firmware" est nécessaire pour faire fonctionner ce périphérique,
et "Parfois" aussi, une mise à jour permettra au fabricant de ce matériel ou/et aux développeurs
de rendre ce matériel plus ou moins "compatible".

Dernière modification par MicP (27-11-2018 16:23:26)

raleur · 27-11-2018 16:31:17

naguam a écrit :

Un dernier petit up au cas où raleur passerai par là et s'y connaîtrait

Je connais quelques trucs, mais pas tous les détails. J'essaierai d'écrire quelque chose quand j'aurais un peu de temps.

naguam · 27-11-2018 20:59:33

Merci pour vos réponses, je suis occupé donc je les lirais en temps voulu. (merci aussi pour processus de démarrage du kernel)
Aussi, sur laptop, le bios la plupart du temps ne permet pas de désactiver ou activer beaucoup de choses.
Sinon, je suis au courant pour les firmwares.

Après, ma question même si c'est l'impression qu'elle a pu donner n'est pas trop sur la conso d'énergie mais comment le matériel inconnu du kernel est géré dans le sens, est-ce que l'adresse inconnue est mise de côté, etc et si il y a des mécanismes software pour ça.

Pas de soucis raleur

Ps: en ce moment je m'intéresse particulièrement au fonctionnement du kernel, et des kernels en général (monolithiques, hybrides, micro) d'où mon intérêt.

Dernière modification par naguam (27-11-2018 21:03:39)

anonyme · 28-11-2018 05:38:00

J'ai juste donné un exemple , j'ai bien compris ta demande.
sinon
si le noyau ne détecte pas (ou mal) le matériel.
si le noyau n' affecte pas de ressources au matériel
si le noyau ne charge pas de modules pour ce matériel (ou en dur dans le noyau)

il sera ignoré pas le système mais électriquement bien présent
par contre j'ai pas compris ceci

est-ce que l'adresse inconnue est mise de côté, etc et si il y a des mécanismes software pour ça.

tu entends quoi par "adresse" ? (il y a un driver en général comme software pour la gestion du matériel ).
sinon après ça dépasse mes compétences sur le sujet.

remarque: il y a des cas particuliers comme le gpu (pas la seule chose ) ou le noyau va détecter sa présence , si il ne le connaît pas , il va tenter un driver générique (mais les ressources nécessaires ne seront pas toutes présentes et bien déclarées).
ps: dans le cas d une machine standard , il y a au moins deux bios chargé au démarrage , celui de la carte mère et celui du gpu (si gpu discret sinon incorporé dans le bios de la CM)
le noyau va lire les informations des bios en priorité. (après aucune idée de ce qu il se passe ..... ).
Comme dit un certain matou Force et Courage

naguam · 28-11-2018 13:53:54

Quand je parle d'adresse, c'est qu'il me semble que c'est comme ça que par exemple, il différencie une clef usb d'une souris, un gpu d'une carte réseau en pcie.

Dernière modification par naguam (28-11-2018 13:54:13)

raleur · 28-11-2018 22:57:18

Ce qui suit concerne plus particulièrement les périphériques "plug&play" connectés à un bus de type PCI ou USB.

Il y a deux niveaux de communication entre le noyau et un périphérique :
- le niveau bas "bus"
- le niveau haut "fonctionnel"

La communication au niveau bus est commune à tous les périphériques connectés par un même type de bus : PCI, USB, SATA... Elle ne sert pas à faire fonctionner le périphérique mais à le détecter, l'identifier, énumérer ses ressources (plages mémoire et E/S, interruptions...), détecter sa déconnexion... Cette communication est assurée par le pilote du bus.

La communication au niveau fonctionnel est spécifique à chaque modèle de périphérique, ou à chaque classe de périphérique s'il s'agit d'un périphérique standard (clavier, souris, stockage de masse, contrôleur AHCI...). Cette communication est assurée par le pilote spécifique du périphérique ou de la classe de périphérique, qui s'appuie sur le pilote du bus. Elle a pour but d'utiliser le périphérique et de le faire fonctionner.

Quand un périphérique est détecté sur un bus, il est d'abord interrogé par le pilote du bus pour l'identifier. Le périphérique renvoie diverses informations sur lui-même, dont plusieurs identifiants :
- identifiant constructeur (propre à chaque type de bus)
- identifiant produit (propre à chaque constructeur)
- identifiant de classe (propre à chaque type de bus)

Ce sont par exemple les informations qu'on peut afficher avec lspci ou lsusb. On peut aussi les retrouver dans l'arborescence de /sys/bus/.

Le noyau va ensuite notifier divers composants logiciels du système qui se sont enregistrés pour recevoir ces informations :
- les pilotes compilés en dur dans le noyau
- les pilotes en modules déjà chargés
- le démon udev

Lorsqu'un pilote du noyau compilé en dur ou en module chargé reconnaît les identifiants d'un périphérique présent qu'il sait gérer, il s'associe à lui et le prend en charge. D'autre part, chaque pilote plug&play compilé en module contient une liste de combinaisons d'identifiants de périphériques qu'il sait gérer sous forme d'alias. C'est ce qui est affiché par modinfo dans les lignes "alias:" pour un module donné. Il peut s'agir par exemple de couples d'identifiants constructeur+produit pour le pilote d'un périphérique particulier, ou d'identifiants de classe pour le pilote d'un périphérique générique.

Lorsqu'udev est notifié par le noyau de la détection d'un périphérique, il exécute modprobe avec la combinaison d'identifiants renvoyés. Modprobe recherche une correspondance avec un module dans le fichier /lib/modules/$(uname -r)/modules.alias, qui a été créé par depmod en scannant l'ensemble des modules présents dans /lib/modules/$(uname -r) lors de l'installation du noyau. Si une correspondance est trouvée, le module est chargé et prend le périphérique en charge.

smolski · 29-11-2018 03:59:14

Impec, mis dans le wiki ici :
https://debian-facile.org/doc:systeme:peripheriques

MicP · 29-11-2018 04:01:34

Et avant même qu'un seul des octets accessibles depuis un des disque dur ou de sa carte contrôleur ne soit lu,
et donc avant même qu'un quelconque système d'exploitation ne soit lancé,

certains composants présents sur la carte mère ou et certaines de leurs fonctionnalités
peuvent se retrouver complètement ou partiellement inaccessibles
simplement car le BIOS leur aura demandé de ne plus répondre à certaines commandes,

comme par exemple les composants qui gèrent les ventilateurs de refroidissement du microprocesseur
qui, ne permettront plus l'écriture de certain de leurs registres qu'à une routine spécifique à ce BIOS
en interdisant ainsi complètement l'accès en écriture à un quelconque système d'exploitation
ou autre composant, mais tout en laissant d'autres registres accessibles en lecture.

Quand une machine exécute le POST du BIOS, (dans certaines conditions mais en général c'est toujours le cas)
elle lancera l'exécution d'une autre routine du BIOS d'une carte graphique (si présente) ou autre carte RAID, etc.
avant de terminer son travail,

et certains vecteurs d'interruption standard du BIOS et adresses d'entrée/sortie peuvent alors êtres remappés,
par d'autres BIOS intégrés sur certaines cartes contrôleur de disque, carte vidéo, ou autre composant spécifique,
qui aura été ajouté ou retiré de la machine.

=======
Linux (comme d'autres SE) peut aussi, et d'ailleurs il le fait depuis longtemps, détourner certaines routines interruptions
vers ses propres routines et remapper les adresses d'entrées/sorties permettant l'accès à certains composants.

Mais bon, le sujet est aussi énorme que la quantité et la diversité des composants constituant les différentes cartes mères,
multiplié par le nombre de façon de les interconnecter, multiplié par le nombre de versions de BIOS, UEFI,
multiplié par le nombre de périphériques qu'il serait possible de connecter à la machine,
multiplié par le nombre de systèmes d'exploitations, etc.
⁫

Dernière modification par MicP (29-11-2018 05:59:40)

naguam · 29-11-2018 12:55:33

Merci pour toutes ces informations

Debian-facile

#1 18-11-2018 22:20:08

[Résolu] Gestion du matériel par le kernel

#2 19-11-2018 21:41:16

Re : [Résolu] Gestion du matériel par le kernel

#3 20-11-2018 08:20:26

Re : [Résolu] Gestion du matériel par le kernel

#4 22-11-2018 07:23:02

Re : [Résolu] Gestion du matériel par le kernel

#5 24-11-2018 21:25:21

Re : [Résolu] Gestion du matériel par le kernel

#6 27-11-2018 07:18:46

Re : [Résolu] Gestion du matériel par le kernel

#7 27-11-2018 14:12:13

Re : [Résolu] Gestion du matériel par le kernel

#8 27-11-2018 16:21:23

Re : [Résolu] Gestion du matériel par le kernel

#9 27-11-2018 16:31:17

Re : [Résolu] Gestion du matériel par le kernel

#10 27-11-2018 20:59:33

Re : [Résolu] Gestion du matériel par le kernel

#11 28-11-2018 05:38:00

Re : [Résolu] Gestion du matériel par le kernel

#12 28-11-2018 13:53:54

Re : [Résolu] Gestion du matériel par le kernel

#13 28-11-2018 22:57:18

Re : [Résolu] Gestion du matériel par le kernel

#14 29-11-2018 03:59:14

Re : [Résolu] Gestion du matériel par le kernel

#15 29-11-2018 04:01:34

Re : [Résolu] Gestion du matériel par le kernel

#16 29-11-2018 12:55:33

Re : [Résolu] Gestion du matériel par le kernel

Pied de page des forums