On Fri, 11 Jan 2002 [EMAIL PROTECTED] wrote:
[ message mal posté, je laisse l'auteur poster l'original, mais vu que
j'ai déjà écrit la réponse cela serait dommage de la laisser tomber
]
> Dans le répertoire /dev/ , on trouve d'innonmbrables noms ne
> correspondant à rien, parce qu'ils désignent un matériel non présent sur
> la machine. Des noms pour je ne sais combien de disques durs, avec je ne
Juste. (détail technique: il ne s'agit pas vraiment/seulement de noms,
mais de points d'entrées de pilotes, liés au système de fichier sous un
device-special-file. Ce qui importe comme dans tous les UNIX pas
super-modernes ce sont les numéros MAJOR et MINOR, cf la sortie de ls -l
ainsi que /usr/src/linux/Documentation/devices.txt. Les noms sont des
conventions. mv /dev/sda /dev/truc_scsi_premier_disque change cette
convention).
A cela j'ajoute qu'il faut distinguer:
1 le support matériel compilé dans le kernel / disponible en module
On peut avoir compilé le support IDE disque sans avoir celui-ci
installé physiquement dans la machine (p.ex. une machine SCSI
seulement)
On peut avoir installé un périphérique sans avoir configuré
son support (recompilation du kernel, activation du module
concerné automatiquement ou manuellement).
Exemple: Red Hat 7.2, si le disque où Linux est installé n'est
pas SCSI mais qu'il existe une carte SCSI dans le
système et que Red Hat peut la détecter
automatiquement, ne va pas charger le module noyau
carte correspondant (ni les gestionnaires
disques/tape/CD), mais configurer celui-ci via
kmod (/etc/modules.conf ou /etc/conf.modules). Au
premier accès à un périphérique existant ou non dans
/dev, le bus SCSI sera scanné par l'insertion du
pilote matériel, et seul à ce moment /proc/scsi/scsi
sera à jour.
[ comportement tout à fait logique d'ailleurs.
Seule critique: scanner le bus provoque en général
un SCSI RESET, certaines configurations (p.ex.
compression tape) peuvent disparaître
si le module est aussi déchargé automatiquement.
C'est une des raisons qui me fait préférer le
chargement en dur dans /etc/modules comme peut
le faire la Debian. L'autre étant que p.ex.
en 2.2.x, `st' avait parfois des problèmes à
allouer ses buffers DMA longtemps après le
démarrage. Autrement, on peut quand même saluer
le fait que la Red Hat détecte cette carte.
]
2 les périphériques installés dans la machine physiquement
On peut dans certains cas détecter un périphérique sans avoir
de support du tout pour. Ils apparaissent en général dans un
bus système (PCI, PCMCIA, etc).
P.ex: /sbin/lspci # ou cat /proc/pci
cf le message sur cardctl pour PCMCIA p.ex.
3 les périphériques détectés ET configurés
Ceux-ci apparaissent en général dans les logs systèmes, et
dans des fichiers de `ressources' (cat /proc/interrupts, etc).
> sais combien de partitions, etc. Pourquoi pas? Le problème, c'est de
> savoir quels sont les noms "actifs", je veux dire: les noms
> correspondant à un élément existant sur la machine, et reconnu par le
C'est légitime. Mais en vertu de ce qui précède, cette requête mélange
allégrement les trois catégories définies. Il faut comprendre que dans
certains cas il n'est même pas possible de déterminer si une carte X est
installée (ISA sans PnP p.ex.) sans le pilote déterminé, et/ou une
configuration correcte du matériel. Les machines modernes PC utilisent des
bus à autoconfiguration -- comme ceux que l'on trouvait dès 1985 sur des
machines genre Amiga -- voire des bus à autoconfiguration magouillée (ISA
PNP) plutôt que des adresses fixes, etc, et donc ce genre de problèmes se
pose de moins en moins.
La seule chose que l'on peut regretter c'est que la catégorie 3 ne
provoque pas automatiquement une mise à jour de /dev. Mais cela
empêcherait bien sûr le chargement et la détection de matériel à la
demande (cf exemple Red Hat ci-dessus) si les périphériques non catégorie
3 n'étaient pas dans /dev.
> système. Existe-t-il une commande permettant de savoir quels sont les
> noms "attribués"?
- La commande dmesg donne nombre d'informations intéressantes quant au
pilotes et périphériques détectés (catégorie 3, parfois catégorie 1
non 3 avec une erreur)
- lsmod donne les modules du kernel chargés, qui sur des kernels
modulaires donne une bonne information sur la catégorie 3.
- certains fichiers dans /proc, comme /proc/interrupts donne les noms de
pilotes associés à des interruptions (catégorie 3 toujours)
- il y a aussi /proc/scsi/scsi, /proc/pci/... etc, qui donnent
des informations sur la catégorie 2, pas forcément catégorie 3.
- fdisk -l /dev/sda # donne les partitions définies
On a parlé à de nombreuses reprises de ce qui précède, lors du diagnostic
de problèmes / comment savoir comment est accédé un périphérique.
Une alternative intéressante à l'ancien modèle /dev UNIX est le devfs, le
device file-system, une spécificité Linux, où les entrées sont générées
dynamiquement en fonction des périphériques effectivement disponibles
(enfin c'est l'impression que cela donne -- pas encore essayé).
devfs est disponible comme patch à 2.2.x et comme option de compilation de
2.4.x: à ma connaissance aucune distribution ne propose ce système par
défaut pour le moment.
Les modifications de droits d'accès sont alors perdus (configurés selon
une table fixe, encore que l'on peut aussi les restaurer si nécessaire à
l'aide d'un daemon en user-space).
Je n'ai pour l'instant aucune expérience de devfs. Je ne sais pas, en
particulier, dans quelle mesure devfs empêche le chargement à la demande
de modules (genre: mount /dev/scd0 /mnt -> chargement modules SCSI,
bas-niveau chip, sr).
Un avantage certain de devfs est un nommage plus UNIX des disques
physiques: au lieu de p.ex. /dev/sdb (deuxième disque SCSI) on aura alors
/dev/bus/scsi/0/0/3/0, si p.ex. ce deuxième disque SCSI se trouve sur le
SCSI ID 3. Faire ainsi peut sembler plus compliqué: c'est cependant la
seule méthode pour éviter des changements de noms de disques physiques en
cas d'insertion de périphériques avec ID plus petite. Maintenant que les
`labels' se généralisent sur les partitions, cela est moins important,
mais les labels se trouvent au niveau du système de fichier, pas des block
devices ou des périphériques non disques: cela reste important p.ex. pour
l'accès générique aux périphériques SCSI (/dev/sgX), qu'on utilise pour le
gravage de CD, ou la configuration/interrogation bas niveau de
périphériques disques ou cassettes: p.ex. savoir le nombre d'erreurs
corrigées en DDS/DAT, ou encore l'accès direct raw-device.
[ je ne connais pas en détail le nommage de devfs, ce qui précède est
l'idée générale ]
Tout ça pour dire qu'un ls /dev, pour le moment, ne donne pas d'indication
sur le matériel supporté par le kernel, le matériel présent dans le
système, ni une intersection entre ces deux.
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.
