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.
