Bonjour,
J'ai un répertoire /dev comme tout le monde avec plein de mystères là
dedans.
Je sais que si je fais un lien symbolique de /dev/ttyS0 vers /dev/modem,
j'ai mon modem. Ça tombe bien, c'est ce qu'il me faut ;-))
Mais je branche ma calculatrice TI 92 sur un port série, comme connaître le
nom de dev associé ?
Si je branche mon GPS sur un même port série, même question ?
Et si j'utilise le port //, quel est le dev ?
En bref, comment connaître le dev associé à un périphérique quelconque ?
Hier, en bidouillant la connexion de ma calculatrice, j'ai supprimé par
erreur un /dev/cua1 (ancien dev du port série, il me semble). Visiblement,
ce n'est pas grave. Mais, si je voulais réparer, comment me faudrait-il m'y
prendre ? Peut-on, de façon générale, "créer" un /dev/machin_chose qui est
pile sur l'adresse d'un périphérique ?
Voilà, j'espère avoir été clair.
Bonne journée à tous,
Dominique
[ on repond plutot en dessous du texte auqel on repond : http://www.giromini.org/usenet-fr/repondre.html ]
Merci pour ce lien.
Quel est le rôle de devfs ? Visiblement, ce n'est pas un logiciel. Disons tout au moins que je ne l'ai pas sur ma distriution (Aurox 9.3).
Cela depend de ce qu'on prend commme definition de logiciel ... C'est une option du noyau : ca ne s'installe pas comme "d'habitude".
Aïe... ;-))
Bonne journée, Dominique
Rakotomandimby Mihamina
Dominique wrote:
- Est-il "impératif" d'installer devfs ? Notez bien que, apparemment, ça fait 46 ans que je vis sans devfs en m'en portant bien ;-))
Je ne sais pas. en tout cas, si il existe c'est qu'il a une utilité. De plus il est censé faciliter la gestion des devices, puisque justement, il cree automatiquement les devices, alors qu'il fallait une gymnastique avec mknod et/ou MAKEDEV sans ...
Cela dit, dans une autre enfilade, il est mentionné que devfs (du moins sur le 2.6) est obsolete (donc a ne plus utiliser) et remplacé par udev.
Donc. Dans tous les cas, si vous avez un souci il faudra d'abord choisir soit de l'installer, soit de ne pas l'installer, puisque la creation de votre device "prot serie" semble etre une operation faisable avec ou sans.
Le seul avantage a utiliser udev (par exemple) serai que vous contriburiez a son amelioration en l'utilisant, puisque si il y a bug on le saura et on le fera remonter aux developpeur (d'une maniere ou d'une autre). Par contre si il n'y a pas bug, qui sait si le fait que vous l'ayez adopte (et utilis sans souci) aura contribué a ce que cette chose passe du statut experimental a celui de stable ...
- S'il me faut devfs, comment l'installer ?
Activer dans les options udev ou devfs dans noyau. Je ne sais pas si ce truc (udev et/ou devfs) est chargeable en tant que module (auqeul cas nulle recompilation n'est necessaire). Moi je suis adepte de la recompilation du noyau (toutes mes options sont en dur, en general) non pas pour la frime mais que cela m'amuse de voir mon PC travailler un peu ...
- Est-il "impératif" d'installer devfs ? Notez bien que, apparemment, ça
fait 46 ans que je vis sans devfs en m'en portant bien ;-))
Je ne sais pas. en tout cas, si il existe c'est qu'il a une utilité.
De plus il est censé faciliter la gestion des devices, puisque
justement, il cree automatiquement les devices, alors qu'il fallait une
gymnastique avec mknod et/ou MAKEDEV sans ...
Cela dit, dans une autre enfilade, il est mentionné que devfs (du moins
sur le 2.6) est obsolete (donc a ne plus utiliser) et remplacé par udev.
Donc. Dans tous les cas, si vous avez un souci il faudra d'abord
choisir soit de l'installer, soit de ne pas l'installer, puisque la
creation de votre device "prot serie" semble etre une operation faisable
avec ou sans.
Le seul avantage a utiliser udev (par exemple) serai que vous
contriburiez a son amelioration en l'utilisant, puisque si il y a bug on
le saura et on le fera remonter aux developpeur (d'une maniere ou d'une
autre). Par contre si il n'y a pas bug, qui sait si le fait que vous
l'ayez adopte (et utilis sans souci) aura contribué a ce que cette chose
passe du statut experimental a celui de stable ...
- S'il me faut devfs, comment l'installer ?
Activer dans les options udev ou devfs dans noyau.
Je ne sais pas si ce truc (udev et/ou devfs) est chargeable en tant que
module (auqeul cas nulle recompilation n'est necessaire).
Moi je suis adepte de la recompilation du noyau (toutes mes options sont
en dur, en general) non pas pour la frime mais que cela m'amuse de voir
mon PC travailler un peu ...
- Est-il "impératif" d'installer devfs ? Notez bien que, apparemment, ça fait 46 ans que je vis sans devfs en m'en portant bien ;-))
Je ne sais pas. en tout cas, si il existe c'est qu'il a une utilité. De plus il est censé faciliter la gestion des devices, puisque justement, il cree automatiquement les devices, alors qu'il fallait une gymnastique avec mknod et/ou MAKEDEV sans ...
Cela dit, dans une autre enfilade, il est mentionné que devfs (du moins sur le 2.6) est obsolete (donc a ne plus utiliser) et remplacé par udev.
Donc. Dans tous les cas, si vous avez un souci il faudra d'abord choisir soit de l'installer, soit de ne pas l'installer, puisque la creation de votre device "prot serie" semble etre une operation faisable avec ou sans.
Le seul avantage a utiliser udev (par exemple) serai que vous contriburiez a son amelioration en l'utilisant, puisque si il y a bug on le saura et on le fera remonter aux developpeur (d'une maniere ou d'une autre). Par contre si il n'y a pas bug, qui sait si le fait que vous l'ayez adopte (et utilis sans souci) aura contribué a ce que cette chose passe du statut experimental a celui de stable ...
- S'il me faut devfs, comment l'installer ?
Activer dans les options udev ou devfs dans noyau. Je ne sais pas si ce truc (udev et/ou devfs) est chargeable en tant que module (auqeul cas nulle recompilation n'est necessaire). Moi je suis adepte de la recompilation du noyau (toutes mes options sont en dur, en general) non pas pour la frime mais que cela m'amuse de voir mon PC travailler un peu ...
PS : où puis-je trouver la signification des /dev comme tu as commencé à me l'indiquer ?
/usr/src/linux/Documentation/devices.txt (fourni par le package kernel-source)
ou /usr/share/doc/kernel-doc*/devices.txt (fourni par le package kernel-doc)
Exact. Merci pour l'info. Je vois d'ailleurs que ce fichier texte est évolutif... Bonne journée, Dominique
no_spam
On Tue, 15 Jun 2004 13:44:45 +0200, Dominique wrote:
Rakotomandimby Mihamina wrote:
Moi je suis adepte de la recompilation du noyau etc...
J'ai peeeeuuuurrrr (des chauves-souris aussi) de la compilation du noyau...
Il ne faut pas, ce n'est qu'un bout de code comme un autre :-)
Pour completer ce qui a été dit: devfs a été conçu pour résoudre le cauchemar habituel de /dev: les devices sont crées au moment ou ils sont réputés exister et être supportés par le kernel. Ca fait gagner pas mal de place sur le disque (et énormément d'inodes) et surtout ça accélère énormément les appels systèmes qui doivent résoudre les noms, dans /dev: le nombre de fichier existant dans un /dev statique est dément et rechercher un fichier dans le temps devient très couteux. De plus, les developpeurs kernel ont décidé d'en finir avec l'architecture "flat" du /dev traditionnel et de regrouper les devices par catégories. Par soucis de compatibilité, ils ont aussi développé un démon qui crée dynamiquement des liens symboliques entre les devices crées avec le nouveau système de nommage et l'ancien système et gère également les droits d'accès. Le défaut de cette approche est que ça engendre un grand nombre de messages entre le kernel et ce démon (bien que la plupart pourraient être optionels, sur une distrib qui supporterait le nouveau système de nommage dans toutes les applis...).
La nouvelle solution (udev) consiste à refaire devfs entièrement en espace user (rien dans le kernel, donc) pour limiter le nombre de messages liés à la gestion des devices. Cette approche est aussi plus souple puisque le système de nommage des fichiers peut être entièrement configurable sans avoir à jamais toucher au kernel. L'inconvénient (car il y en a quand même un) est que les devices sont de nouveau stockés sur le disque et non plus en mémoire, ce qui ralentit fortement l'accès aux devices, à moins qu'ils n'utilisent un ram-disque spécifique pour /dev. Je précise que ces ralentissement ne se resentent qu'au moment de la recherche d'un device (généralement pour un "open") et non pas quand on se sert du device ensuite.
On Tue, 15 Jun 2004 13:44:45 +0200, Dominique wrote:
Rakotomandimby Mihamina wrote:
Moi je suis adepte de la recompilation du noyau etc...
J'ai peeeeuuuurrrr (des chauves-souris aussi) de la compilation du noyau...
Il ne faut pas, ce n'est qu'un bout de code comme un autre :-)
Pour completer ce qui a été dit:
devfs a été conçu pour résoudre le cauchemar habituel de /dev:
les devices sont crées au moment ou ils sont réputés exister et
être supportés par le kernel.
Ca fait gagner pas mal de place sur le disque (et énormément d'inodes)
et surtout ça accélère énormément les appels systèmes qui doivent
résoudre les noms, dans /dev: le nombre de fichier existant dans
un /dev statique est dément et rechercher un fichier dans le temps
devient très couteux.
De plus, les developpeurs kernel ont décidé d'en finir avec
l'architecture "flat" du /dev traditionnel et de regrouper les devices
par catégories.
Par soucis de compatibilité, ils ont aussi développé un démon qui
crée dynamiquement des liens symboliques entre les devices crées
avec le nouveau système de nommage et l'ancien système et gère également
les droits d'accès.
Le défaut de cette approche est que ça engendre un grand nombre de
messages entre le kernel et ce démon (bien que la plupart pourraient
être optionels, sur une distrib qui supporterait le nouveau système
de nommage dans toutes les applis...).
La nouvelle solution (udev) consiste à refaire devfs entièrement
en espace user (rien dans le kernel, donc) pour limiter le nombre
de messages liés à la gestion des devices.
Cette approche est aussi plus souple puisque le système de nommage
des fichiers peut être entièrement configurable sans avoir à jamais
toucher au kernel.
L'inconvénient (car il y en a quand même un) est que les devices
sont de nouveau stockés sur le disque et non plus en mémoire,
ce qui ralentit fortement l'accès aux devices, à moins qu'ils
n'utilisent un ram-disque spécifique pour /dev.
Je précise que ces ralentissement ne se resentent qu'au moment de
la recherche d'un device (généralement pour un "open") et non pas
quand on se sert du device ensuite.
On Tue, 15 Jun 2004 13:44:45 +0200, Dominique wrote:
Rakotomandimby Mihamina wrote:
Moi je suis adepte de la recompilation du noyau etc...
J'ai peeeeuuuurrrr (des chauves-souris aussi) de la compilation du noyau...
Il ne faut pas, ce n'est qu'un bout de code comme un autre :-)
Pour completer ce qui a été dit: devfs a été conçu pour résoudre le cauchemar habituel de /dev: les devices sont crées au moment ou ils sont réputés exister et être supportés par le kernel. Ca fait gagner pas mal de place sur le disque (et énormément d'inodes) et surtout ça accélère énormément les appels systèmes qui doivent résoudre les noms, dans /dev: le nombre de fichier existant dans un /dev statique est dément et rechercher un fichier dans le temps devient très couteux. De plus, les developpeurs kernel ont décidé d'en finir avec l'architecture "flat" du /dev traditionnel et de regrouper les devices par catégories. Par soucis de compatibilité, ils ont aussi développé un démon qui crée dynamiquement des liens symboliques entre les devices crées avec le nouveau système de nommage et l'ancien système et gère également les droits d'accès. Le défaut de cette approche est que ça engendre un grand nombre de messages entre le kernel et ce démon (bien que la plupart pourraient être optionels, sur une distrib qui supporterait le nouveau système de nommage dans toutes les applis...).
La nouvelle solution (udev) consiste à refaire devfs entièrement en espace user (rien dans le kernel, donc) pour limiter le nombre de messages liés à la gestion des devices. Cette approche est aussi plus souple puisque le système de nommage des fichiers peut être entièrement configurable sans avoir à jamais toucher au kernel. L'inconvénient (car il y en a quand même un) est que les devices sont de nouveau stockés sur le disque et non plus en mémoire, ce qui ralentit fortement l'accès aux devices, à moins qu'ils n'utilisent un ram-disque spécifique pour /dev. Je précise que ces ralentissement ne se resentent qu'au moment de la recherche d'un device (généralement pour un "open") et non pas quand on se sert du device ensuite.
