Je reposte, apr�s (d�but de) lecture : La premi�re remarque vient imm�diatement apr�s l'argument "massue" produit d�s qu'on lit qq chose sur devfs : ================================================= D'ailleurs l'exemple suivant devrait suffire � convaincre de l'utilit� de devfs:
sans devfs root@foo:/#ls /dev | wc -l --> plus de 1500 avec devfs root@foo:/#ls /dev | wc -l --> moins de 500 ================================================= Cet argument me g�ne. En ceci que tout le monde sait (ou peut remarquer) que dans le r�pertoire /dev, les fichiers (sp�ciaux) qui s'y trouvent n'occupent AUCUN espace disque. Le champ "taille" est remplac� par le majeur et le mineur du fichier. Ces deux nombres permettent (en gros) au syst�me d'identifier l'adresse physique du p�riph�rique. Je ne connais pas la fa�on exacte (physique) de cr�er ce r�pertoire, mais quelque chose me dit que /dev n'est rien d'autre qu'un FICHIER-r�pertoire, � structure particuli�re. - Un fichier-r�pertoire ordinaire contient (sch�matiquement) deux colonnes : N� de i-node/nom du fichier (du lien ou "r�f�rence"), DANS CE fichier-r�pertoire. Si bien que lorsqu'on tape "ls -l /chemin/nom_de_fichier", ce que fait la commande ls n'est rien d'autre que d'aller chercher le n� d'i-node correspondant � "/chemin/nom_de_fichier" stock� dans le fichier-r�pertoire "/chemin", puis d'aller lire les infos concernant ce i-node dans la table des i-node. Si on applique ceci � /dev, �a revient � dire que ce qui est lu par le syst�me n'est rien d'autre que le fichier-r�pertoire /dev et que le temps gagn� � ce niveau l� correspond au temps gagn� pour lire un fichier de 500 lignes au lieu de 1500 (lignes de quelques octets chacune - sur une 6.1, le fichier /dev "mesure" ~32k). Sachant que pour lire 32k ne prend pas une heure de plus que pour lire un fichier de 1k, je me demande quel est le gain de temps sur un syst�me bas� sur devfs par rapport � un syst�me non bas� sur devfs. Y'at-il eu un bench qq part? Curieux de d�couvrir une quelconque am�lioration notable de performances (combien de nanosecondes?). Cet argument me semble fallacieux et quelque peu malhonn�te. Pour les autres arguments en faveur de devfs (lisibilit� du fs en particulier) je suis pour l'instant plut�t convaincu. Rosaire Fabrice FACORAT a �crit : > > le ven 14-12-2001 � 22:05, Rosaire AMORE a �crit : > > > De mon strict point de vue d'�minent fain�ant je me pose en effet la > > question : quel apport? En terme de performances? En terme de clart� du > > fonctionnement du syst�me? > > Je vais probablement me faire incendier, mais quand je vois � vue de pif > > l'investissement en temps que �a semble devoir me demander pour > > ma�triser ce bordel (j'ai pas encore eu le temps de m'y plonger > > s�rieusement et je ne vois pas bien quand je l'aurais avant juin/juillet > > prochain)... la question se pose (pour moi). > > Peut-�tre se pose-t-elle simplement parce que je n'ai encore jamais lu > > de document clair sur le sujet comme ceux que j'ai pu lire dans des docs > > constructeur sur le fonctionnement de /dev/* et mknod. > > En toute humilit�... > > A vos lance flammes!... > > Rosaire > > http://www-106.ibm.com/developerworks/library/l-fs4.html > http://gcu-squad.org/?viewtip+28 > -- > http://perso.wanadoo.fr/linux_wizard/index.html > - > Il ne suffit pas de dire : je me suis trompe ; > il faut dire comment on s'est trompe. > > -- Claude Bernard > > ------------------------------------------------------------------------ > Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft? > Rendez-vous sur "http://www.mandrakestore.com";
Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft? Rendez-vous sur "http://www.mandrakestore.com";
