diff --git a/fr_FR.ISO8859-1/books/handbook/backups/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/backups/chapter.sgml
deleted file mode 100644
index 707735ab65..0000000000
--- a/fr_FR.ISO8859-1/books/handbook/backups/chapter.sgml
+++ /dev/null
@@ -1,774 +0,0 @@
-
-
-
- Sauvegardes
- &trans.a.haby;
-
- Les questions de compatibilité matérielle sont aujourd'hui
- les plus problématiques de l'industrie informatique et FreeBSD
- n'en est nullement à l'abri. De ce point de vue, l'avantage qu'a
- FreeBSD de pouvoir être utilisé sur du matériel PC de base et
- peu coûteux devient un problème lorsqu'il faut supporter la
- variété incroyable de composants disponibles sur le marché.
- Il est impossible de donner une liste exhaustive des matériels
- compatibles avec FreeBSD, mais ce chapitre est un catalogue des
- pilotes de périphériques inclut dans FreeBSD et des matériels que
- chaque pilote supporte. Si possible et approprié, des notes ont
- ajoutées sur les matériels eux-mêmes. Vous pouvez aussi vous
- référer au chapitre Configurer
- le noyau de FreeBSD de ce manuel pour avoir
- la liste des matériels supportés.
-
- FreeBSD est un projet bénévole qui n'a pas les moyens de financer
- un service de tests, nous reposons sur vous, les utilisateurs, pour une
- grande part des informations que fournit ce catalogue. Si vous avez
- l'expérience personnelle d'un matériel qui fonctionne ou ne fonctionne
- pas avec FreeBSD, faites-le nous savoir par courrier électronique
- à la &a.doc;. Les questions concernant les matériels compatibles doivent
- être adressées à la &a.questions; (voyez la section
- Listes
- de diffusion pour plus d'information). Quand vous nous faites
- parvenir de l'information ou posez une question, n'oubliez pas s'il vous
- plaît de préciser exactement quelle version de FreeBSD vous utilisez et
- de donner le maximum de détails sur votre configuration
- matérielle.
-
-
- * A propos des sauvegardes sur disquettes
-
-
-
-
-
- Formats de bandes
-
- Les principaux types de bandes sont les 4mm, 8mm, QIC, les mini-cartouches
- et les DLT.
-
-
- 4mm (DDS: “Digital Data
- Storage”)
-
- Les bandes 4mm sont en train de remplacer les bandes QIC comme format usuel
- de sauvegarde pour les stations de travail. Cette tendance s'est accélérée
- lorsque Conner a racheté Archive, dominant sur le marché des lecteurs QIC,
- et a arrêté la production de ces derniers. Les bandes 4mm sont petites et
- silencieuses, mais n'ont pas la réputation de fiabilité des bandes 8mm. Les
- cartouches sont moins coûteuses et plus petites (3 x 2 x 0.5 pouces, 76 x 51
- x 12 mm) que les cartouches 8mm. Leurs durées de vie sont faibles et comparables,
- car elles utilisent toutes les deux un procédé de lecture/écriture en hélice.
-
- Leur débit va de ~150kB/s à ~500kB/s au maximum. Leur capacité varie de
- 1.3 GB à 2.0 GB. La compression matérielle, disponible sur la plupart des
- lecteurs, double approximativement leur capacité. Il existe des lecteurs
- multiples avec changeur de bande automatique qui ont jusqu'à six unités de
- lecture/écriture. La capacité totale qu'ils gèrent atteint 240 GB.
-
- Les têtes 4mm, comme les têtes 8mm, utilisent un procédé de lecture/écriture
- en hélice. Ils présentent donc tous deux les avantages et les inconvénients de ce
- procédé.
-
- Il faut sortir les bandes après 2.000 utilisations ou 100 sauvegardes
- complètes.
-
-
-
- Bandes 8mm (Exabyte)
-
- Les unités de bandes 8mm sont les unités SCSI les plus courantes; c'est le
- meilleure choix de bandes amovibles. Il y a une unité Exabyte 8mm de 2GB sur
- presque chaque site. Les bandes 8mm sont fiables, silencieuses et pratiques.
- Les cartouches ne sont pas chères et d'encombrement faible (4.8 x 3.3 x 0.6
- pouces; 122 x 84 x 15 mm). Un des inconvénients de ce format est la durée de
- vie relativement courte des bandes et des têtes du fait de la grande vitesse
- de défilement de la bande devant les têtes.
-
- Leur débit va ~250kB/s à ~500kB/s au maximum. Leur capacité commence à
- 300 MB jusqu'à 7 GB. La compression matérielle, disponible sur la plupart des
- lecteurs, double approximativement leur capacité. Il existe des lecteurs
- simples et multiples, qui accueillent six unités et 120 cartouches. Ils
- disposent de changeurs de bandes automatiques. Ils gèrent une capacité de
- stockage de 840+ GB.
-
- L'enregistrement des données utilisent un procédé en hélice. Les têtes
- sont en biais par rapport à la bande (environ 6 degrés). La bande fait un
- angle de 270 degrés avec le cylindre sur lequel se trouvent les têtes. Ce
- cylindre tourne en même temps que la bande défile. On aboutit donc à une
- grande densité de données et des pistes très serrées qui vont de biais d'un
- bord de la bande à l'autre.
-
-
-
- QIC
-
- Les bandes et les lecteurs QIC-150 sont, peut-être, le format le plus
- courant. Les lecteurs de bandes QIC sont les moins chers des supports de
- sauvegarde “sérieux”. Leur inconvénient par contre est le
- coût des bandes. Les bandes QIC sont chères par rapport aux bande 4mm et 8mm,
- près de 5 fois le coût au GB. Mais, si une demi-douzaine de bandes vous
- suffit, le format QIC est peut-être le bon choix. QIC est le format le
- plus répandu. Il y a un lecteur QIC d'une densité ou
- d'une autre sur chaque site. C'est là la difficulté, il y a de nombreuses
- densités différentes pour des bandes physiquement semblables (parfois
- même identiques). Les lecteurs QIC ne sont pas silencieux. Ils se
- positionnent bruyamment avant d'enregistrer et on les entend lorsqu'ils
- lisent, enrregistrent ou se positionnent sur la bande. Les bandes QIC
- sont volumineuses (6 x 4 x 0.7 pouces; 15.2 x 10.2 x 1.7 mm).
- Les Mini-cartouches,
- qui utilisent aussi des bandes 1/4" sont décrites par ailleurs. On ne trouve
- pas d'unités multi-bandes avec changeur.
-
- Leur débit va de ~150kB/s à ~500kB/s au maximum. Leur capacité varie de
- 40 MB à 15 GB. La compression matérielle est disponible sur de
- nombreux modèles récents. On utilise de moins en moins les lecteurs
- QIC; ils sont remplacés par les lecteurs DAT.
-
- Les données sont enregistrées sur des pistes sur la bande. Les pistes
- sont parallèles à la bande et vont d'une extrémité à l'autre. Le nombre de
- pistes et donc la largeur des pistes dépend de la capacité de la bande. La
- plupart, sinon toutes les unités récentes sont au moins compatibles en
- lecture (mais souvent aussi en écriture) avec les anciennes. Le format
- a une bonne réputation de fiabilité (la mécanique est plus simple est
- plus robuste que celle du système en hélice).
-
- Les bandes sont utilisables pour 5.000 sauvegardes.
-
-
-
- * Mini-Cartouches
-
-
-
-
-
- DLT
-
- Les DLT ont le taux de transfert le plus rapide de tous les types
- de lecteurs décrits ici. La bande d'1/2" (12.5mm) est contenue dans
- une seule cartouche à bobine (4 x 4 x 1 pouces; 100 x 100 x 25 mm).
- La cartouche est munie d'une trappe basculante sur une face latérale
- entière. Le lecteur ouvre cette trappe pour saisir le début de la
- bande. Cette amorce comporte une découpe ovale que le lecteur utilise
- pour “crocheter” la bande. La bobine d'entraînement se
- trouve dans le lecteur. Tous les autres types de cartouches décrits
- ici (les bandes neuf pistes sont la seule exception) incorporent les
- bobines de stockage et d'entraînement.
-
- Leur débit est d'environ 1.5MB/s, trois fois celui des bandes 4mm,
- 8mm et QIC. La capacité d'une bande va de 10GB à 20GB. Il y a des unités
- avec changeur de bandes et des unités avec plusieurs lecteurs/enregistreurs
- qui vont de 5 à 900 bandes et de 1 à 20 lecteurs, ce qui procure une
- capacité totale de 50GB à 9TB.
-
- Les données sont enregistrées sur des pistes parallèles à la direction
- de défilement (tout comme les bandes QIC). L'écriture se fait sur deux pistes
- à la fois. La durée de vie des têtes de lecture/écriture est relativement
- longue; une fois que la bande s'arrête, il n'y a pas de déplacement des têtes
- par rapport à la bande.
-
-
-
- Utiliser une bande neuve pour la première fois
-
- La première fois que vous essayer de lire ou d'écrire sur une bande vierge,
- l'opération échoue. La console affiche des messages du type:
-
-
- st0(ncr1:4:0): NOT READY asc:4,1
-st0(ncr1:4:0): Logical unit is in process of becoming ready
-
-
- Il n'y a pas de bloc d'identification (bloc numéro 0) sur la bande.
- Tous les lecteurs QIC écrivent un bloc d'identification sur la bande
- depuis l'adoption du standard QIC-525. Il y a deux solutions:
-
-
-
- mt fsf 1 fait écrire au lecteur le bloc
- d'identification sur la bande.
-
-
-
- Utilisez le bouton du panneau frontal pour éjecter la bande,
-
- réinsérez la bande et utilisez
-
- dump
- 8
- pour écrire dessus,
-
-
- dump
- 8 produira l'erreur DUMP:
- End of tape detected et la console affichera:
- HARDWARE FAILURE info:280 asc:80,96,
-
- rembobinez la bande avec: mt rewind,
-
- les manipulations ultérieures sur la bande fonctionneront.
-
-
-
-
-
-
- Programmes de sauvegarde
-
- Les trois principaux programmes sont:
-
- dump
- 8,
-
- tar
- 1,
- et
-
- cpio
- 1.
-
-
- Dump et Restore
-
-
- dump
- 8
- et
- restore
- 8
- sont les programmes de sauvegarde traditionnels d'Unix.
- Ils considérent la bande comme une suite de blocs de disque, en dessous
- du niveau d'abstraction que constituent les fichiers, liens et répertoires
- créés par les systèmes de fichiers.
-
- dump
- 8
- sauvegarde des entrées de "périphériques", des systèmes
- de fichiers complets, et non des sous-ensembles d'un système de fichiers
- ou des arborescences de répertoires qui se répartissent sur plusieurs
- systèmes de fichiers, via des liens symboliques créés avec
-
- ln
- 1
- ou en montant un système de fichiers sur un autre.
-
- dump
- 8
- n'écrit pas de fichiers ou répertoires sur la bande, mais
- écrit les blocs de données dont sont constitués les fichiers et
- les répertoires.
- dump
- 8
- a quelques particularités qui datent de la
- Version 6 d'ATT Unix (circa 1975). Les paramètres par défaut
- conviennent aux bandes 9 pistes (6250 bpi) et non aux supports
- à haute densité que l'on trouve maintenant (jusqu'à 62,182 ftpi).
- Il faut surcharger ces valeurs par défaut sur la ligne de
- commande pour utiliser la capacité des bandes actuelles.
-
-
- rdump
- 8
- et
- rrestore
- 8 sauvegardent les données
- via le réseau sur une unité de bandes qui se trouve sur une
- autre machine. Les deux programmes se servent de
-
- rcmd
- 3
- et
- ruserok
- 3 pour accéder à l'unité de
- bandes distante. L'utilisateur qui effectue la sauvegarde doit donc
- avoir un accès rhosts à la machine distante. Les
- arguments de
- rdump
- 8
- et
- rrestore
- 8
- doivent être compatibles avec la machine distante (e.g.
- si vous sauvegardez d'une machine FreeBSD sur un lecteur Exabyte
- installé sur un ordinateur Sun appelé
- komodo, utilisez: /sbin/rdump 0dsbfu 54000
- 13000 126 komodo:/dev/nrst8 /dev/rsd0a 2>&1) Attention:
- Autoriser les commandes rhosts a des conséquences
- pour la sécurité. Evaluez soigneusement votre situation.
-
-
-
- Tar
-
-
- tar
- 1
- date aussi de la Version 6 d'ATT Unix (circa
- 1975).
- tar
- 1
- travaille en coopération avec le système de fichiers;
-
- tar
- 1
- écrit des fichiers et des répertoires sur la bande.
-
- tar
- 1
- ne supporte pas toutes les options que permet
-
- cpio
- 1, mais
- tar
- 1 ne demande pas
- l'inhabituelle concaténation de commandes qu'utilise
-
- cpio
- 1
- .
-
- La plupart des versions de
- tar
- 1
- ne donnent pas la possibilité de sauvegarde en réseau. La
- version GNU de
- tar
- 1, que FreeBSD utilise,
- supporte les périphériques distants avec la même syntaxe que
- rdump. Pour sauvegarder avec
- tar
- 1
- sur une unité Exabyte installée sur un Sun appelé
- komodo, utilisez: /usr/bin/tar cf komodo:/dev/nrst8 .
- 2>&1. Avec les versions sans support pour des
- périphériques distants, vous pouvez utilisez un tuyau (“pipe”)
- et
- rsh
- 1 pour envoyer les données
- sur le lecteur distant.
-
-
-
- Cpio
-
-
- cpio
- 1 est le programme Unix
- original pour l'échange de fichiers par bandes magnétiques.
-
- cpio
- 1 dispose d'options (entre
- beaucoup d'autres) pour intervertir les octets, utiliser différents
- formats d'archivage et envoyer les données à d'autres programmes.
- C'est cette dernière possibilité qui fait de
-
- cpio
- 1 un excellent choix pour
- les supports d'installation.
- cpio
- 1 ne sait pas parcourir
- l'arborescence d'un répertoire et il faut lui passer la liste
- des fichiers via
- STDIN.
-
-
- cpio
- 1 ne permet pas la
- sauvegarde sur le réseau et il faut utiliser un tuyau (“pipe”)
- et
- rsh
- 1 pour envoyer les données sur une
- unité distante.
-
-
-
- Pax
-
-
- pax
- 1 est la réponse IEEE/POSIX à
- tar et cpio. Au fil des ans, les
- différentes versions de tar et cpio
- sont devenues légérement incompatibles. Donc, au lieu de batailler pour
- les standardiser entièrement, POSIX a défini un nouvel utilitaire d'archivage.
- pax essaie de lire nombre de formats
- tar1 et
- cpio1 en
- plus de ses propres nouveaux formats. Son jeu de commandes ressemble plus à
- celui de cpio qu'à celui de
- tar.
-
-
-
- Amanda
-
- Amanda
- (Advanced Maryland Network Disk Archiver - Système Avancé d'Archivage
- de Disques en Réseau du Maryland ) est un système d'archivage client/serveur
- plutôt qu'un simple programme. Un serveur Amanda archivera sur une seule
- unité de bandes un nombre quelconque d'ordinateurs qui ont un client
- Amanda et un accès réseau au serveur Amanda. Un problème habituel sur
- les sites qui ont de nombreux disques volumineux est le temps disponible
- pour la sauvegarde. Amanda résoud ce problème. Amanda peut utiliser un
- “disque intermédiaire” pour sauvegarder plusieurs systèmes de fichiers
- à la fois. Amanda crée des “jeux d'archive”, un ensemble de bandes
- utilisées pour une période donnée pour créer une sauvegarde complète de tous les
- systèmes de fichiers listés dans ses fichiers de configuration.
- Le “jeu d'archive” contient aussi les sauvegardes nocturnes
- incrémentales (ou différentielles) de tous les systèmes de fichiers.
- Pour restaurer un système de fichiers endommagé, il faut la sauvegarde
- complète la plus récente et les sauvegardes incrémentales.
-
- Le fichier de configuration permet un contrôle en finesse des
- sauvegardes et du trafic qu'Amanda génére sur le réseau. Amanda peut
- utiliser n'importe lequel des programmes de sauvegarde décrits plus
- haut pour écrire les données sur bande. Amanda existe sous forme
- pré-compilée ou source, il n'est pas installé par défaut.
-
-
-
- Ne rien faire
-
- “Ne rien faire” n'est pas un logiciel, mais c'est la
- stratégie de sauvegarde la plus utilisée. Il n'y a aucun investissement.
- Il n'y a pas de planification des sauvegardes à suivre. Juste dire non.
- Si quelque chose arrive à vos données, souriez et débrouillez-vous!
-
- Si votre temps et vos données ne valent pas grand chose, alors
- “Ne rien faire” est le programme de sauvegarde le mieux
- adapté à votre ordinateur. Mais prenez garde, Unix est un bon outil,
- vous pouvez vous rendre compte au bout de six mois que vous avez une
- collection de fichiers utiles.
-
- “Ne rien faire” est la bonne méthode pour sauvegarder
- /usr/obj et les autres répertoires qui peuvent
- facilement être recréés par votre ordinateur. Par exemple, les fichiers
- qui constituent ces pages ont été générés à partir de fichiers
- SGML. Il n'est pas nécessaire d'archiver ces fichiers
- HTML. Les fichiers source
- SGML sont sauvegardés régulièrement.
-
-
-
- Quel est le meilleur programme de sauvegarde?
-
-
- dump
- 8 Point.
- Elizabeth D. Zwicky a soumis à rude épreuve tous les programmes de
- sauvegarde dont nous avons parlé. Le choix de
- dump
- 8 s'impose pour préserver toutes
- vos données et les particularités des systèmes de fichiers Unix.
- Elizabeth a créé des systèmes de fichiers avec une grande variété
- de particularités inhabituelles et a testé chacun des programmes
- en faisant une sauvegarde et une restauration. Parmi les spécificités
- testées : fichiers avec des trous, fichiers avec des trous et des blocs
- de caractères “null”, fichiers dont les noms comportaient des
- caractères inhabituels, fichiers illisibles ou dans lesquels il n'était
- pas possible d'écrire, périphériques, fichiers dont la taille changeait
- pendant la sauvegarde, fichiers créés ou détruits en cours de sauvegarde,
- et bien d'autres encore. Elle a présenté les résultats de ces test au
- LISA V en Octobre 1991. Voyez ses Tests d'endurance des programmes
- de sauvegarde et de restauration.
-
-
-
- Procédure de restauration d'urgence
-
-
- Avant le désastre
-
- Il y a quatre étapes à mettre en oeuvre en prévision d'un désastre éventuel.
-
- Tout d'abord, imprimez le label de chacun de vos disques
- (e.g. disklabel sd0 | lpr), votre table des systèmes de fichiers
- (/etc/fstab) et tous les messages de démarrage,
- en deux exemplaires.
-
- Deuxièmement, vérifiez que vos disquettes de démarrage
- et de reprise d'urgence
- (boot.flp et fixit.flp)
- incluent tous vos périphériques. La meilleure façon de le vérifier
- est de redémarrer avec la disquette de démarrage dans le lecteur
- et de contrôler les messages de démarrage. Si tous les périphériques
- y figurent et sont opérationnels, passez à la troisième étape.
-
- Sinon, vous devez créer deux disquettes de démarrage sur-mesure
- avec un noyau qui puisse monter tous vos disques et accéder à votre
- unité de bandes. Ces disquettes doivent contenir:
-
- fdisk
- 8,
- disklabel
- 8,
- newfs
- 8,
- mount
- 8, et celui des programmes
- de sauvegarde que vous utilisez. L'édition de liens de ces
- programmes doit être statique. Si vous utilisez
-
- dump
- 8, les disquettes doivent
- inclure
-
- restore
- 8.
-
- Troisièmement, faites régulièrement des sauvegardes sur bandes. Toutes
- les modifications effectuées après la dernière sauvegarde peuvent être
- irrémédiablement perdues. Protégez vos bandes de sauvegarde en écriture.
-
- Quatrièmement, testez vos disquettes (soit boot.flp
- et fixit.flp, soit les deux disquettes sur-mesure que vous
- avez créées à la seconde étape) et vos bandes de sauvegarde. Prenez note de
- la procédure (de restauration). Rangez ces notes avec la disquette de démarrage,
- les impressions et les bandes de sauvegarde. Vous serez si préoccupé quand vous
- devrez restaurer que ces notes peuvent vous éviter de détruire vos bandes de
- sauvegarde (Comment? En tapant accidentellement
- tar cvf /dev/rst0 au lieu de tar xvf ce qui
- écraserait vos bandes de sauvegarde).
-
- Par mesure de sécurité, créez une disquette de démarrage et deux bandes
- de sauvegarde à chaque fois. Rangez-les dans un lieu éloigné. Le sous-sol
- du même batiment n'est pas un endroit éloigné. Un certain
- nombre de compagnies du World Trade Center l'ont appris à leurs dépends. Un
- endroit éloigné doit être physiquement significativement séparé de vos
- ordinateurs et de vos disques.
-
- Voici un exemple de procédure pour créer une disquette de démarrage:
-
-
- /mnt/sbin/init
-gzip -c -best /sbin/fsck > /mnt/sbin/fsck
-gzip -c -best /sbin/mount > /mnt/sbin/mount
-gzip -c -best /sbin/halt > /mnt/sbin/halt
-gzip -c -best /sbin/restore > /mnt/sbin/restore
-
-gzip -c -best /bin/sh > /mnt/bin/sh
-gzip -c -best /bin/sync > /mnt/bin/sync
-
-cp /root/.profile /mnt/root
-
-cp -f /dev/MAKEDEV /mnt/dev
-chmod 755 /mnt/dev/MAKEDEV
-
-chmod 500 /mnt/sbin/init
-chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt
-chmod 555 /mnt/bin/sh /mnt/bin/sync
-chmod 6555 /mnt/sbin/restore
-
-#
-# créer les fichiers spéciaux de périphériques
-#
-cd /mnt/dev
-./MAKEDEV std
-./MAKEDEV sd0
-./MAKEDEV sd1
-./MAKEDEV sd2
-./MAKEDEV st0
-./MAKEDEV pty0
-cd /
-
-#
-# créer une table des systèmes de fichiers minimale
-#
-cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd <
-
-
-
- Après le désastre
-
- La question cruciale est: votre matériel a-t-il survécu? Vous avez fait
- des sauvegardes régulières, donc vous n'avez pas besoin de vous inquiéter
- pour les logiciels et les fichiers.
-
- Si le matériel a subi des dégats, remplacez d'abord ce qui a été
- endommagé.
-
- Si votre matériel est en état, récupérez vos disquettes. Si vous
- utilisez une disquette sur-mesure, démarrez en mode mono-utilisateur
- (tapez -s à l'invite boot:). Sautez
- le paragraphe suivant.
-
- Si vous utilisez les disquettes boot.flp et
- fixit.flp, continuez à lire. Mettez la disquette
- boot.flp dans le premier lecteur et démarrez
- l'ordinateur. Le menu d'installation d'origine s'affiche à l'écran,
- choisissez l'option Fixit--Repair mode with CDROM or
- floppy (Reprise avec une disquette ou un CDROM). Insérez la
- disquette fixit.flp quand on vous la demande.
- restore et les autres programmes dont vous avez besoin
- sont dans le répertoire /mnt2/stand.
-
- Restaurez séparement chaque système de fichiers.
-
- Essayez
- mount
- 8
- (e.g. mount /dev/sd0a
- /mnt) sur la partition racine de votre premier disque.
- Si le label du disque est endommagé, utilisez
- disklabel
- 8 pour repartitionner et
- libeller le disque comme l'indique le label que vous avez imprimé
- et mis de côté. Utilisez
-
- newfs
- 8 pour recréer les systèmes
- de fichiers. Remontez la partition racine de la disquette en
- lecture/écriture (mount -u -o rw /mnt). Utilisez
- votre programme de restauration et vos bandes de sauvegardes pour
- restaurer les fichiers de ce système de fichiers (e.g.
- restore vrf /dev/st0). Démontez le système de fichiers
- (e.g. umount /mnt). Répétez l'opération pour chacun
- des systèmes de fichiers endommagés.
-
- Une fois que le système fonctionne de nouveau, faites une sauvegarde
- sur de nouvelles bandes. Ce qui a causé la panne ou la perte de données
- peut se reproduire. Une heure de perdue maintenant peut vous épargner
- d'autres ennuis plus tard.
-
-
-
- * Je ne me suis pas préparé au désastre, que faire?
-
-
-
-
-
-
-
-
diff --git a/fr_FR.ISO8859-1/books/handbook/contrib/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/contrib/chapter.sgml
deleted file mode 100644
index 98e18dd6a4..0000000000
--- a/fr_FR.ISO8859-1/books/handbook/contrib/chapter.sgml
+++ /dev/null
@@ -1,5888 +0,0 @@
-
-
- Collaborer à FreeBSD
- &trans.a.dntt;
-
- Contribution de &a.jkh;.
-
- Alors, comme ça vous voulez collaborer à FreeBSD ?
- C'est génial ! Toute aide peut toujours servir, et FreeBSD est
- un de ces systèmes qui s'appuie sur les
- contributions de sa base d'utilisateurs pour survivre. Vos
- contributions ne sont pas seulement appréciées, elles sont vitales
- pour la progression de FreeBSD !
-
- Contrairement à ce que certaines personnes et
- peut-être vous-même pouvez croire, vous n'avez pas à être un
- expert programmeur ou un ami très proche de l'équipe principale
- de FreeBSD pour faire accepter votre contribution. Le
- développement du projet FreeBSD est fait par une grande et
- toujours plus nombreuse, équipe de collaborateurs
- à travers le monde, dont les âges et l'expertise techniques
- sont très variables, et il y aura toujours plus de travail à
- faire que de gens qui peuvent le faire.
-
- Comme le projet FreeBSD est responsable de tout
- l'environnement du système d'exploitation (et de son
- installation) et pas seulement juste du noyau ou de quelques
- utilitaires éparpillés, notre liste TODO
- (à faire) s'étend sur une large gamme de tâches, depuis la
- documentation, les beta-test et présentation jusqu'à des types de
- développement du noyau hautement spécialisés.
- Quelque soit votre niveau de compétence, il y aura sûrement
- quelque chose que vous pourrez faire pour aider le projet !
-
- Les entités commerciales engagées dans des entreprises
- relatives à FreeBSD sont encouragées à nous contacter. Vous
- avez besoin d'une extension spéciale pour faire marcher votre
- produit ? Vous nous trouverez attentifs à votre requête, du
- moment que celle-ci ne soit pas trop hors-sujet. Vous
- travaillez sur un produit à valeur ajoutée ? Dites-le nous !
- Nous serons peut-être capable de coopérer sur certains aspects.
- Le monde du logiciel libre va à l'encontre de nombreuses
- suppositions sur la manière dont les logiciels sont
- développés, vendus et maintenus durant son cycle de vie,
- et nous vous invitons à lui donner au moins un second regard.
-
-
-
-
- Les besoins
-
- La liste de tâches et de sous-projets qui suit, représente
- une sorte d'amalgame des différentes listes
- TODO de l'équipe de base, et des demandes
- d'utilisateurs que nous avons regroupés depuis ces derniers
- mois. Lorsque cela a été possible, nous avons rangés ces
- tâches par degré d'urgence. Si vous êtes interessé par le fait
- de travailler sur l'une des tâches que vous voyez ici, envoyez
- un mail au coordinateur en cliquant sur leur nom. Si aucun
- coordinateur n'a été désigné, peut-être voudriez-vous vous
- désigner ?
-
-
- Tâches de première priorité
-
- Les tâches suivantes sont considérées comme urgentes,
- généralement parce qu'elles représentent
- quelque chose posant des problèmes, ou parce qu'on en a
- désespérement besoin.
-
-
-
- démarrage en 3 étapes. coordination globale :
- &a.hackers;
-
-
-
- Faire un marquage de disque compatible WinNT
- de telle sorte que la troisième étape puisse fournir
- un mapping précis de la géométrie BIOS pour les
- disques.
-
-
-
-
-
- Problèmes du système de fichiers. Coordination
- globale : &a.fs;
-
-
-
- Corriger le système de fichiers MSDOS.
-
-
-
- Nettoyer et documenter le code du système de
- fichier nullfs.
- Coordination : &a.eivind;
-
-
-
- Corriger le système de fichiers d'union.
- Coordination : &a.dg;
-
-
-
-
-
- Implémenter le pilote de disque Int13 vm86.
- Coordination : &a.hackers;
-
-
-
- Nouvelle architecture bus.
-
-
-
-
- Porter les pilotes ISA existant vers la nouvelle
- architecture.
-
-
-
- Déplacer tous le code de gestion d'interruption
- vers les parties appropriées des pilotes de bus.
-
-
-
- Porter les sous-système PCI à la nouvelle
- architecture.
- Coordination : &a.dfr;
-
-
-
- Chercher la bonne manière pour manier les
- périphériques extractibles, puis utiliser ceci comme
- base pour l'implémentation de support de PC-Card et
- CardBus.
-
-
-
- Résoudre une fois pour toute, le problème de
- priorité de détection / attachement.
-
-
-
- Déplacer tous les bus restants vers la nouvelle
- architecture.
-
-
-
-
-
- Problèmes relatifs au noyau.
- Coordination globale : &a.hackers;
-
-
-
- Ajouter une infrastructure pour une meilleure sécurité
- pro-active.
- Coordination globale : &a.security;
-
-
-
- Construire quelque chose comme Tripwire (TM) dans
- le noyau, avec une partie distante et une partie
- locale. Il y a un certain nombre de problèmes
- de cryptographie à prendre en compte pour bien le
- réaliser. Contacter le coodinateur pour plus de
- détails.
- Coordination : &a.eivind;
-
-
-
- Faire de telle sorte que tout le noyau utilise
- suser() au lieu de comparer avec 0.
- Pour l'instant, on n'utilise que la moitié de chaque.
- Coordination : &a.eivind;
-
-
-
- Découper les niveaux de sécurité en plusieurs
- parties, afin de permettre à un administrateur de jeter
- les privilèges qu'il peut jeter. Mettre en place tous
- ces niveaux de sécurité devra avoir malgrès tout
- les mêmes effets qu'actuellement.
- Coordination : &a.eivind;
-
-
-
- Rendre possible le chargement de “programmes
- autorisés à utiliser BPF” puis bloquer BPF
- pour qu'il ne puisse pas accepter d'autres programmes.
- Cela permettrait à BPF d'être utilisé par exemple par
- DHCP, ceci sans permettre à un attaquant de prendre
- contrôle du réseau local.
-
-
-
- Mettre à jour les scripts de vérification de
- sécurité. Nous devrions au moins pouvoir récupérer
- toutes les vérifications d'autres dérivés BSD, et
- ajouter une vérification qu'un système ayant un
- niveau de sécurité ainsi augmenté puisse aussi avoir un
- témoin raisonnable sur les parties concernées.
- Coordination : &a.eivind;
-
-
-
- Ajouter une infrastructure d'autorisation au
- noyau, afin de permettre diverses politiques
- d'autorisation. Une partie de ceci pourrait être fait
- en modifiant suser().
- Coordination : &a.eivind;
-
-
-
- Ajouter du code à la couche NFS afin que l'on ne
- puisse pas faire un chdir ("..") en
- dehors d'une partition NFS,
- Par exemple :
- /usr est une partition UFS avec
- la partition NFS /usr/src exportée.
- Il est à présent possible d'utiliser le gestionnaire
- de fichier NFS pour /usr/src pour
- obtenir l'accès à /usr.
-
-
-
-
-
-
-
-
-
- Tâches de moyenne priorité
-
- Les tâches suivantes doivent être effectuées, mais
- sans urgence particulière :
-
-
-
- Support et gestion de configuration de tous les
- pilotes basés sur KLD.
-
-
-
- Ecrire un gestionnaire de configuration (dans la
- troisième partie du démarrage ?) qui détecterait votre
- matériel de manière propre, et garderait seulement les
- KLDs requis pour votre matériel, etc.
-
-
-
-
-
- PCMCIA/PCCARD.
- Coordination : &a.msmith; et &a.phk;
-
-
-
- Documentation !
-
-
-
- Opération fiable du pilote pcic
- (besoin de test).
-
-
-
- Reconnaissance et prise en charge de
- sio.c (presque fait).
-
-
-
- >Reconnaissance et prise en charge de
- ed.c (presque fait).
-
-
-
- Reconnaissance et prise en charge de
- ep.c (presque fait).
-
-
-
- Reconnaissance et prise en charge du
- mode utilisateur (partiellement fait).
-
-
-
-
-
- Gestionnaire d'énergie avancé.
- Coordination : &a.msmith; et &a.phk;
-
-
-
- sous-pilote APM (presque fait).
-
-
-
- sous-pilote de disques IDE/ATA
- (partiellement fait).
-
-
-
- sous-pilote syscons/pcvt.
-
-
-
- Intégration avec les pilotes PCMCIA/PCCARD
- (suspendu / en cours).
-
-
-
-
-
-
-
-
-
- Tâches de moindre priorité
-
- Les tâches suivantes sont purement esthètiques et
- représentent un tel investissement qu'il semblerait
- qu'elles seront pas accomplie de sitôt :
-
- Les premiers points sont de Terry Lambert
- terry@lambert.org
-
-
-
- Chargeur serveur NetWare (pilote ODI en mode protégé)
- et sous-services pour autoriser l'utilisation de pilotes
- de cartes ODI avec des cartes réseaux.
- Même chose avec les pilotes NDIS et les pilotes
- NetWare SCSI.
-
-
-
- Uni option "évolution système" marchant sur des
- machines sous Linux et pas seulement sur des
- machines sous une version plus anciennes de FreeBSD.
-
-
-
- Multi-processeur symétrique avec préemption du noyau (requiert
- une préemption du noyau).
-
-
-
- Un effort concerté sur les ordinateurs portables.
- Cela est en quelque sorte pris en charge en
- changeant les règles de passage PCMCIA
- et en traitant le gestionnaire d'énergie.
- Mais il y a certaines choses comme la détection de
- l'affichage interne vs. externe et l'utilisation d'une
- résolution d'écran différente en considérant ce fait,
- ne pas arrêter le disque si la machine est refermée, et
- autoriser les cartes pour portable à disparaitre sans
- empêcher la machine de démarrer (même problème que pour le
- PCMIA).
-
-
-
-
-
-
-
- Tâches moins lourdes
-
- La plupart des tâches citées dans la section
- précédente nécessitent soit un investissement
- important en temps, soit une connaissance en
- profondeur du noyau (ou les deux).
- Quoiqu'il en soit, il y a de nombreuses
- tâches utiles pour les
- "programmeurs occasionnels", ou les
- personnes sans compétences en programmation.
-
-
-
- Si vous utilisez FreeBSD-current et que vous
- avez une bonne connexion Internet, il y a une machine
- current.freebsd.org
- qui construit une version complète tous les
- jours — à chaque fois, essayer et
- installer la dernière version depuis ceci et
- reporter toutes les erreurs durant le processus.
-
-
-
- Lire les messages de la liste de diffusion
- freebsd-bugs.
- Il peut y avoir un problème que vous
- pouvez commenter de manière constructive ou alors
- des patches que vous pouvez tester.
- Vous pouvez aussi essayer de résoudre un de ces
- problèmes vous-même.
-
-
-
- Lisez la FAQ et le manuel régulièrement,
- si quelque chose est mal expliqué, pas à jour
- ou simplement complètement faux, dites le
- nous.
- Mieux, envoyez nous le correctif
- (SGML n'est pas difficile à apprendre,
- mais il n'y a pas d'objection à des soumissions
- au format ASCII).
-
-
-
- Aidez à traduire la documentation
- FreeBSD dans votre langue (si elle n'est
- pas déjà disponible) — envoyez juste un
- courrier électronique à &a.doc; demandant si
- quelqu'un est en train d'y travailler.
- Notez que vous ne vous engagez pas
- à traduire chacun des documents FreeBSD ce faisant —
- en fait la documentation dont on a le plus souvent besoin
- est les instructions d'installation.
-
-
-
-
- Lire la liste de diffusion freebsd-questions.
- et les newsgroup comp.unix.bsd.freebsd.misc de
- temps en temps (ou même régulièrement).
- Il peut être très satisfaisant de partager
- ses expérience et aider les gens à résoudre
- leurs problèmes; parfois, vous
- pouvez même ainsi apprendre de nouvelles choses !
- Ces forums peuvent parfois être une source d'idées sur ce
- qu'il faut travailler.
-
-
-
- Si vous connaissez un correctif appliqué
- avec succès à -current mais qui n'a pas été
- appliqué à -stable après un intervalle de temps
- raisonnable (normalement quelques
- semaines), envoyer aux collaborateurs un
- rappel poli.
-
-
-
- Déplacer les logiciels de collaboration de
- src/contrib dans
- l'arborescence source.
-
-
-
- Assurez vous que le code dans
- src/contrib
- est à jour.
-
-
-
- Cherchez les bugs de l'an 2000
- (et corrigez ceux que vous trouvez !)
-
-
-
- Construire l'arbre des sources
- (ou une partie) avec les messages de tous les
- avertissements activés et faire de
- sorte à ce qu'il n'y ait plus ces
- avertissements.
-
-
-
- Corriger les avertissements pour les ports qui
- réalisent des choses obsolètes comme
- gets () ou les inclusions de malloc.h.
-
-
-
- Si vous avez collaboré à un des ports, envoyez vos
- correctifs à leurs auteurs originaux (cela leur facilitera
- la vie lors de la sortie de la prochaine version)
-
-
-
- Suggèrez d'autres tâches pour cette liste !
-
-
-
-
-
-
-
-
- Comment participer
-
- Les contributions au systèmes tombent
- générallement dans l'une de ces 6 catégories :
-
-
- Rapports de bogues et commentaires généraux
-
- Une idée ou une suggestion d'interêt technique
- général devrait être envoyée à
- &a.hackers;.
- les personnes interessées par cela (et qu'un
- grand volume de courrier
- électronique ne dérange pas, devraient s'abonner à
- la liste de diffusion hackers en envoyant un
- courrier électronique à &a.majordomo;.
- Voir les listes de
- diffusions lists pour plus d'informations
- pour ceci et les autres listes de diffusions.
-
- Si vous trouvez un bug ou si vous
- soumettez un changement spécifique, enregistrez
- le en utilisant le programme send-pr (1)
- ou son équivalent
- web.
- Essayez de remplir chaque champ de l'enregistrement de bug.
- A moins qu'ils ne dépassent 65KB, y inclure tous
- les correctifs directement dans l'enregistrement.
- Penser à les compresser et à utiliser
- uuencode (1); s'ils
- dépassent 20KB.
- Charger les grosses soumissions vers ftp.freebsd.org:/pub/FreeBSD/incoming/
-
- Après avoir rempli la fiche d'enregistrement, vous devriez
- recevoir une confirmation avec un numéro d'enregistrement.
- Gardez ce numéro afin que vous puissiez nous soumettre plus de
- détails à propos du problème en envoyant un courrier
- électronique à bug-followup@FreeBSD.ORG.
- Utilisez le numéro comme sujet du message, par exemple
- "Re: kern/3377".
- Toute information supplémentaire sur
- un bug enregistré devrait être soumise de la même
- manière.
-
- Si vous ne recevez aucune confirmation en un temps
- raisonnable (de 3 jours à une semaine suivant votre connexion
- pour le courrier) ou qu'il vous est, pour une raison quelconque,
- impossible d'utiliser la commande send-pr (1), vous pouvez
- demander à quelqu'un de le faire pour vous en envoyant un
- courrier électronique à &a.bugs;.
-
-
-
- Modifications de la documentation
-
- Les modifications dans la documentation sont
- supervisées par &a.doc;.
- Envoyez les soumissions et les modifications (même les
- plus petites sont les bienvenus !) en utilisant
- la commande send-pr
- comme décrit dans
- Soumission de bug
- et commentaires généraux.
-
-
-
- Modification dans le code source existant
-
- Un ajout ou modification dans le code source
- existant est une autre affaire, et dépend beaucoup
- de votre version par rapport à l'état
- courant du développement de base de FreeBSD.
- Il y a une version spéciale du FreeBSD en cours
- de développement, connu sous le nom de
- “FreeBSD-current” qui est
- disponible de diverses manières pour le confort
- des développeurs qui travaillent activement sur
- le système.
- Voir Etre à jour avec
- FreeBSD pour plus d'informations sur
- la manière d'obtenir et d'utiliser
- FreeBSD-current.
-
- Déveloper avec des sources plus anciennes
- signifie que vos modifications peuvent parfois
- devenir trop obsolète ou trop divergentes pour
- permettre une ré-intégration dans FreeBSD.
- On peut limiter cela en souscrivant aux
- listes de diffusion &a.announce; et &a.current;
- où des discussions sur l'état
- courant du système ont lieu.
-
- En supposant que vous pouvez vous arranger pour avoir de
- manière sûre des sources à jour comme base pour vos
- modifications, l'étape suivante consiste à produire
- un ensemble de diffs à envoyer à ceux qui sont chargés
- de maintenir FreeBSD.
- Cela est fait par l'intermédiaire de la commande
- diff (1), avec une préférence pour le formulaire
- “contexte diff”.
- Par exemple :
-
-
- &prompt.user;
- diff -c oldfile newfile
-
- ou
-
- &prompt.user;
- diff -c -r olddir newdir
-
- génèrera un ensemble de contexte diffs pour un fichier
- source ou une hiérarchie de répertoires donné.
- Voir les pages de manuel pour diff (1) pour plus de
- détails.
-
- Une fois que vous avez l'ensemble des diffs (que vous
- pouvez tester avec la commande patch(1), vous devriez les
- soumettre pour qu'ils puissent être inclus dans FreeBSD.
- Utilisez le programme send-pr (1) comme décrit dans
- Rapport de bugs et commentaires
- généraux.
- Ne pas simplement envoyer les diffs à
- &a.hackers; ou ils seront perdus !
- Nous apprécions beaucoup vos soumissions (c'est un
- projet fait par des volontaires !),
- mais parce que nous sommes très occupé, nous ne
- pourrons pas les étudier immédiatement,
- mais cela restera dans la base de
- données jusqu'à ce que nous le fassions.
-
- Si cela vous semble approprié (par exemple si vous avez
- renommé les fichiers), mettre vos modifications dans un fichier
- tar et lancer le programme uuencode (1)
- dessus. Les archives shar sont aussi les
- bienvenues.
-
- Si vos modifications sont potentiellement sensibles, par
- exemple si vous n'êtes pas sûr des problèmes de copyright
- concernant sa distribution, ou si vous n'êtes simplement pas
- prêt à le distribuer sans y avoir jeté un coup d'oeil, alors
- vous devriez l'envoyer directement à &a.core; plutôt que de le
- soumettre avec send-pr(1).
- La liste de diffusion principale atteint un petit
- groupe de personnes qui réalise la
- plupart du travail quotidien de FreeBSD.
- Notez que ce groupe est aussi
- très occupé, et donc que vous ne
- devriez leur envoyer un courrier électronique
- que lorsque cela est réellement nécessaire.
-
- Se réferrer à man 9 intro
- et man 9 style pour plus
- d'informations sur la manière de coder.
- Nous apprécierons le fait que vous soyez au moins au courant de cette
- information avant de nous soumettre du code.
-
-
-
-
- Nouveau code source ou logiciel à valeur ajoutée
- importante
-
- Dans les rares cas d'une collaboration
- importante, ou de l'addition d'une importante
- fonctionnalité à FreeBSD, il devient presque nécessaire
- d'envoyer les modification en les uuncodant dans
- des fichiers tar et en les chargeant sur notre
- site FTP ftp://ftp.FreeBSD.ORG/pub/FreeBSD/incoming.
-
- Lorsque l'on travaille avec un grand volume
- de code, le sujet sensible du copyright revient
- invariablement.
- Les copyrights acceptables pour le code inclu
- dans FreeBSD sont :
-
-
-
- Le copyright BSD. Ce copyright est le plus apprécié
- par son côté “sans attaches” et son
- attractivité générale pour les entreprises commerciales.
- Loin de décourager un tel usage commercial, le
- projet FreeBSD encourage activement une telle
- participation avec interêts commerciaux pour ceux
- qui seraient éventuellement tenté d'investir
- quelque chose dans FreeBSD.
-
-
-
- La licence publique GNU, ou “GPL”.
- Cette licence n'est pas aussi populaire chez nous à
- cause du volume d'efforts supplémentaires demandés
- à celui qui voudrait utiliser le code dans un
- but commercial.
- Mais étant donné la quantité de code de code GPL dont
- nous avons actuellement besoin (compilateur,
- assembleur, formatteur de texte, etc),
- il serait absurde de refuser des
- collaborations sous cette licence.
- Le code sous GPL va dans une différente partie de
- l'arborescence des répertoires :
- /sys/gnu ou
- /usr/src/gnu, et est de ce
- fait très identifiable par quelqu'un dont la
- licence GNU poserait un problème.
-
-
-
- Les collaborations venant avec un autre
- type de copyright doivent
- être soigneusement vérifié avant leur
- inclusion dans FreeBSD.
- Les contributions où des restrictions commerciales
- particulières s'appliquent sont généralement rejetées.
- Les auteurs sont toujours encouragés à mettre ces
- modifications disponibles par leur propre
- moyens.
-
- Pour mettre un copyright de “style
- BSD” sur votre travail, inclure le texte
- suivant au tout début de chaque code source que
- vous voulez protéger, en remplaçant le texte entre les
- %% par l'information appropriée.
-
-
-Copyright (c) %%annee%%
- %%votre_nom_ici%%, %%votre_ville%% %%votre_code_postal%%.
- Tous droits réservés
-
- La redistribution et l'utilisation des sources et des
- formes binaires, avec ou sans modifications, sont
- autorisées si les conditions suivantes soient réunies :
-
-1. Les redistributions du code source doivent conserver
- la notification de copyright ci-dessus, cette liste
- de conditions et le démenti suivant comme premières
- lignes de ce fichier, ceci non modifiés.
-2. Les redistributions sous forme binaire doivent
- reproduire la notification de copyright ci-dessus,
- cette liste de conditions et le démenti suivant
- en documentation et/ou sur les autres supports
- de la distribution.
-
- CE LOGICIEL EST FOURNI EN L'ETAT PAR ''%%VOTRE_NOM_ICI%%''
- ET TOUTES GARANTIES EXPRES OU IMPLICITES, Y COMPRIS,
- MAIS NON LIMITE A, LES GARANTIES IMPLICITES DE LA VALEUR
- MARCHANDE ET PHYSIQUE DANS UN BUT PARTICULIER
- SONT DEMENTIES.
- EN AUCUN CAS %%VOTRE_NOM_ICI%% SERA RESPONSABLE DES
- DOMMAGES DIRECTS, INDIRECTS, FORTUITS, SPECIAUX,
- EXEMPLAIRES, OU CONSECUTIFS (COMPRENANT, MAIS NON
- LIMITÉ A : REMPLACEMENT DES MARCHANDISES OU
- SERVICES; PERTE DE DONNEES, OU DE BENEFICES ;
- OU INTERRUPTION D'AFFAIRES) CAUSEE ET SUR TOUTE
- THEORIE DE RESPONSABILITE, SI DANS LE CONTRAT, LA
- RESPONSABILITE SANS FAUTE INTENTIONNELLE, OU TORT
- (NEGLIGENCE Y COMPRIS OU AUTRES) SURGISSANT EN CONSEQUENCE
- DE L'UTILISATION DE CE LOGICIEL, CECI, MĘME SI INFORME
- DE LA POSSIBILITE D'UN TEL DOMMAGE.
-
- $Id$
-
- Pour votre convenance, une copie de ce texte
- peut être trouvée dans
- /usr/share/examples/etc/bsd-style-copyright.
-
-
-
-
- Contribution financière, matériel
- ou accès Internet
-
- Nous sommes toujours très heureux de
- recevoir des donations pour poursuivre la cause
- du projet FreeBSD, et dans un effort
- volontaire comme le nôtre, un rien peut faire du chemin !
- Les donations de matériel sont également très importantes
- pour augmenter notre liste de périphériques supportés
- puisque nous manquons souvent de fonds pour acheter de tels
- éléments nous-mêmes.
-
-
- <anchor id="donations">Donation de fonds
-
- Comme le projet FreeBSD n'est pas une corporation
- 501(c)(3) (charitable), et par conséquent ne peut
- offrir des réductions fiscales, toute donation
- sera acceptée avec reconnaissance au nom du projet par
- FreeBSD, inc.
-
- FreeBSD, Inc. a été fondé au début de
- l'année 1995 par &a.jkh; et &a.dg; avec le but de
- promouvoir les objectifs du projet de FreeBSD
- et de lui donner une présence minimale de corporation.
- Tout fond donné (ainsi que tous bénéfices qui
- peuvent par la suite être réalisés par
- FreeBSD, inc.) seront exclusivement employés à
- poursuivre les buts du projet.
-
- Tous les chèques doivent être adressés
- à l'ordre de FreeBSD, Inc. et envoyés à
- l'adresse suivante :
-
-
- FreeBSD, Inc.
- c/o Jordan Hubbard
- 4041 Pike Lane, Suite F
- Concord
- CA, 94520
-
-
- (utilisant l'adresse de
- Walnut Creek CDROM en attendant qu'une boite
- postale puisse être ouverte)
-
- Les transferts de fonds peuvent être
- directement envoyés à :
-
-
- Bank Of America
- Concord Main Office
- P.O. Box 37176
- San Francisco
- CA, 94137-5176
-
- Routage #: 121-000-358
- Compte #: 01411-07441 (FreeBSD, Inc.)
-
-
- Toute correspondance à propos de dons, devrait être
- envoyé directement à Jordan
- Hubbard jkh@FreeBSD.org,
- soit par courrier électronique, soit à l'adresse
- postale de FreeBSD, Inc. donnée ci-dessus.
-
- Si vous ne voulez pas être listé
- dans notre section donateur le spécifier
- lors de votre don, merci !
-
-
-
- Contribution matérielle
-
- La contribution en matériel tombant dans une
- des trois catégories suivantes sont joyeusement
- acceptées par le projet FreeBSD :
-
-
-
- Le matériel à caractère général comme
- les disques, la mémoire ou des systèmes
- complets doivent être envoyés à l'adresse
- de FreeBSD, Inc. donnée dans la section
- donation de fonds.
-
-
-
- Le matériel pour tests de compatibilité
- en cours est apprécié.
- Nous sommes actuellement en train de rassembler un
- laboratoire de test pour tous les composants
- supportés par FreeBSD, ceci afin que
- des tests de regressions puissent être effectués à
- chaque nouvelle version.
- Nous manquons actuellement d'importants
- composants (cartes éthernet, cartes mère, etc)
- et si vous voulez faire un tel don, contactez
- &a.dg; pour des informations sur le
- matériel dont nous avons toujours besoin.
-
-
-
- Du matériel non supporté actuellement
- par FreeBSD et que vous voudriez voir supporté.
- Contactez &a.core; avant de nous envoyer ces
- articles car il faut que nous trouvons
- un développeur acceptant de se charger de cette
- tâche avant d'accepter ce nouveau matériel.
-
-
-
-
-
- Contribution d'accès Internet
-
- Nous pouvons toujours utiliser de
- nouveaux sites mirroirs pour les FTP,
- WWW ou cvsup.
- Si vous voulez devenir un tel mirroir, contactez les
- administrateurs du projet FreeBSD admin@FreeBSD.ORG
- pour plus d'informations.
-
-
-
-
-
-
-
-
- Les donateurs
-
- Le projet FreeBSD est en dette envers les
- donateurs suivants et voudrait les remercier
- publiquement ici !
-
-
-
- Contributeurs au projet du
- serveur central :
-
- Les personnes à titre privé ou commercial
- suivantes ont rendu possible pour le projet
- FreeBSD de construire la machine serveur
- centrale pour éventuellement remplacer freefall.freebsd.org
- en donnant les articles suivants :
-
-
-
- Ade Barkah mbarkah@freebsd.org et son
- employeur, Hemisphere
- Online, ont donné un
- Pentium Pro (P6) 200Mhz
- CPU
-
-
-
- ASA
- Computers ont donné
- une carte mère Tyan
- 1662.
-
-
-
- Joe McGuckin joe@via.net
- de ViaNet Communications
- a donné un contrôleur ethernet
- Kingston.
-
-
-
- Jack O'Neill jack@diamond.xtalwind.net
- a donné une carte
- contrôleur NCR 53C875 SCSI.
-
-
-
- Ulf Zimmermann ulf@Alameda.net de Alameda
- Networks a donné 128MB
- de mémoire , un disque
- de 4 Gb et la valise.
-
-
-
-
-
- Fonds directs :
-
- Les personnes suivantes ont généreusement
- contribué - à titre privé ou commercial -
- directement aux fonds du projet :
-
-
-
- Annelise Anderson
- ANDRSN@HOOVER.STANFORD.EDU
-
-
-
- Matt Dillon dillon@best.net
-
-
-
- Epilogue Technology
- Corporation
-
-
-
- Sean Eric Fagan
-
-
-
- Don Scott Wilde
-
-
-
- Gianmarco Giovannelli
- gmarco@masternet.it
-
-
-
- Josef C. Grosch joeg@truenorth.org
-
-
-
- Robert T. Morris
-
-
-
- Chuck Robey chuckr@freebsd.org
-
-
-
- Kenneth P. Stox ken@stox.sa.enteract.com de
- Imaginary Landscape,
- LLC.
-
-
-
- Dmitry S. Kohmanyuk dk@dog.farm.org
-
-
-
- Laser5
- du Japon (une partie de leur bénéfice de la vente
- de leurs différents CD-ROM de FreeBSD.
-
-
-
- Fuki
- Shuppan Publishing Co. ont donné
- une partie de leur bénéfice sur Hajimete
- no FreeBSD (débuter sous FreeBSD)
- aux projets FreeBSD et XFree86.
-
-
-
- ASCII
- Corp. ont donné une partie de leur
- bénéfice de vente sur des produits sur FreeBSD.
-
-
-
- Yokogawa
- Electric Corp ont généreusement donné des
- fonds significatifs au projet FreeBSD.
-
-
-
- BuffNET
-
-
-
- Pacific
- Solutions
-
-
-
-
-
- Contribution matérielle :
-
- Les personnes suivantes à titre privé ou
- commercial, ont généreusement contribué en
- matériel pour les tests et le
- développement/support des pilotes de
- périphérique :
-
-
-
- Walnut Creek CDROM pour avoir fourni
- le Pentium P5-90 et le 486/DX2-66 EISA/VL
- qui sont actuellement utilisés pour notre
- travail de développement, cela sans parler
- de l'accès réseau et d'autres dons
- de matériels.
-
-
-
- TRW Financial Systems, Inc. nous a
- fourni 130 PC, trois serveurs de fichiers
- 68 GB, douze Ethernets, deux routeurs et
- un commutateur ATM pour déboguer un
- code sans disque.
-
-
-
- Dermot McDonnell a donné un
- lecteur CDROM Toshiba XM3401B
- actuellement utilisé dans freefall.
-
-
-
- Chuck Robey a contribué par son lecteur de
- bande pour le travail expérimental.
-
-
-
- Larry Altneu larry@ALR.COM,
- and &a.wilko;, ont donné des lecteurs de
- bandes Wangtek and Archive QIC-02 afin d'améliorer
- les wt pilotes.
-
-
-
- Ernst Winter ewinter@lobo.muc.de
- a contribué par son lecteur de disquette
- 2.88 MB au projet.
- Cela augmentera la pression pour réécrire le
- pilote du lecteur de disquette.;-)
-
-
-
- Tekram
- Technologies a envoyé chacun de
- leur carte adapteur hôte DC-390, DC-390U
- et DC-390F FAST and ULTRA SCSI pour
- les tests de regression des pilotes
- NCR et AMD avec leur cartes.
- Ils peuvent être aussi acclamé pour avoir rendu leurs
- sources de pilotes disponibles sur les serveur
- FTP pour les systèmes s'exploitation libres.ftp://ftp.tekram.com/scsi/FreeBSD.
-
-
-
- Larry M. Augustin ont
- contribué non seulement avec une carte
- Symbios Sym8751S SCSI mais aussi par un ensemble de
- livres de données, y compris la prochaine puce
- Sym53c895 chip avec support Ultra-2
- et LVD, et pour le dernier manuel de programmation
- avec des informations sur la manière d'utiliser
- sûrement les fonctionnalités avancées de la dernière puce
- Symbios SCSI chips. Merci beaucoup !
-
-
-
- Christoph Kukulies kuku@freebsd.org
- a donné un lecteur CDROM FX120 12 vitesse
- Mitsumi pour le développement de pilote
- CDROM IDE.
-
-
-
-
-
- Contributeurs spéciaux :
-
-
-
- Walnut Creek CDROM
- a donné plus que nous pourrions le dire (voir le document de
- l'historique pour plus de détails.
- En particulier, nous voudrions les remercier pour le matériel
- original utilisé pour freefall.FreeBSD.ORG, notre principale
- machine de développement, et pour thud.FreeBSD.ORG, une machine de
- test et de construction. Nous leur sommes aussi gré pour
- le financement de plusieurs collaborateurs au fil des années, et
- pour nous avoir fourni un accès illimité à leur connexion T1
- à l'Internet.
-
-
-
- interface
- business GmbH, Dresden qui ont patiemment
- supportés &a.joerg; qui a souvent préféré le travail FreeBSD
- au travail pour lequel il était payé, et a utilisé leur
- (coûteuse) connexion EUnet Internet lorsque sa connexion privée
- devenait trop lente pour tavailler décemment avec ...
-
-
-
- Berkeley Software Design,
- Inc. ont contribué en donnant leur émulateur
- DOS au reste du monde BSD, qui est utilisé dans la commande
- dosemu.
-
-
-
-
-
-
-
-
- Les anciens de l'équipe principale
-
- Les personnes suivantes ont été membre de l'équipe
- de base de FreeBSD durant la période indiquée.
- Nous les remercions de leurs efforts passés au
- service du projet FreeBSD.
-
- Dans un ordre chronologique brut :
-
-
-
- Guido van Rooij (1995 - 1999)
-
-
-
- John Dyson (1993 - 1998)
-
-
-
- Nate Williams (1992 - 1996)
-
-
-
- Rod Grimes (1992 - 1995)
-
-
-
- Andreas Schulz (1992 - 1995)
-
-
-
- Geoff Rehmet (1993 - 1995)
-
-
-
- Paul Richards (1992 - 1995)
-
-
-
- Scott Mace (1993 - 1994)
-
-
-
- Andrew Moore (1993 - 1994)
-
-
-
- Christoph Robitschko (1993 - 1994)
-
-
-
- J. T. Conklin (1992 - 1993)
-
-
-
-
-
- Collaborateurs des logiciels dérivés
-
- Ce logiciel dérive originelement du 386BSD
- version 0.1 de William F. Jolitz.
- Ce logiciel a été essentiellement réimplémenté depuis
- la version 4.4BSD-Lite fourni par le Computer
- Science Research Group (CSRG) à l'université de
- Californie à Berkeley et des académies
- collaboratices associées.
-
- Il ya aussi des portions de NetBSD et
- OpenBSD qui ont été intégrés dans le code FreeBSD,
- et nous voulons de ce fait remercier tous les
- collaborateurs de NetBSD et OpenBSD pour leur travail.
-
- (Dans l'order alphabétique par le prénom) :
-
-
-
- ABURAYA Ryushirou rewsirow@ff.iij4u.or.jp
-
-
-
- AMAGAI Yoshiji amagai@nue.org
-
-
-
- Aaron Bornstein aaronb@j51.com
-
-
-
- Aaron Smith aaron@tau.veritas.com
-
-
-
- Achim Patzner ap@noses.com
-
-
-
- Ada T Lim ada@bsd.org
-
-
-
- Adam Baran badam@mw.mil.pl
-
-
-
- Adam Glass glass@postgres.berkeley.edu
-
-
-
- Adam McDougall mcdouga9@egr.msu.edu
-
-
-
- Adrian Colley aecolley@ois.ie
-
-
-
- Adrian Hall adrian@ibmpcug.co.uk
-
-
-
- Adrian Mariano adrian@cam.cornell.edu
-
-
-
- Adrian Steinmann ast@marabu.ch
-
-
-
- Adrian T. Filipi-Martin
- atf3r@agate.cs.virginia.edu
-
-
-
- Ajit Thyagarajan unknown
-
-
-
- Akio Morita
- amorita@meadow.scphys.kyoto-u.ac.jp
-
-
-
- Akira SAWADA unknown
-
-
-
- Akira Watanabe
- akira@myaw.ei.meisei-u.ac.jp
-
-
-
- Akito Fujita fujita@zoo.ncl.omron.co.jp
-
-
-
- Alain Kalker
- A.C.P.M.Kalker@student.utwente.nl
-
-
-
- Alan Bawden alan@curry.epilogue.com
-
-
-
- Alan Cox alc@cs.rice.edu
-
-
-
- Alec Wolman wolman@cs.washington.edu
-
-
-
- Aled Morris aledm@routers.co.uk
-
-
-
- Alex garbanzo@hooked.net
-
-
-
- Alex D. Chen
- dhchen@Canvas.dorm7.nccu.edu.tw
-
-
-
- Alex G. Bulushev bag@demos.su
-
-
-
- Alex Le Heux alexlh@funk.org
-
-
-
- Alexander B. Povolotsky tarkhil@mgt.msk.ru
-
-
-
- Alexander Leidinger
- netchild@wurzelausix.CS.Uni-SB.DE
-
-
-
- Alexandre Snarskii snar@paranoia.ru
-
-
-
- Alistair G. Crooks agc@uts.amdahl.com
-
-
-
- Allan Saddi asaddi@philosophysw.com
-
-
-
- Allen Campbell allenc@verinet.com
-
-
-
- Amakawa Shuhei amakawa@hoh.t.u-tokyo.ac.jp
-
-
-
- Amancio Hasty hasty@star-gate.com
-
-
-
- Amir Farah amir@comtrol.com
-
-
-
- Amy Baron amee@beer.org
-
-
-
- Anatoly A. Orehovsky tolik@mpeks.tomsk.su
-
-
-
- Anatoly Vorobey mellon@pobox.com
-
-
-
- Anders Nordby nickerne@nome.no
-
-
-
- Anders Thulin Anders.X.Thulin@telia.se
-
-
-
- Andras Olah olah@cs.utwente.nl
-
-
-
- Andre Albsmeier
- Andre.Albsmeier@mchp.siemens.de
-
-
-
- Andre Oppermann andre@pipeline.ch
-
-
-
- Andreas Haakh ah@alman.robin.de
-
-
-
- Andreas Kohout shanee@rabbit.augusta.de
-
-
-
- Andreas Lohr andreas@marvin.RoBIN.de
-
-
-
- Andreas Schulz unknown
-
-
-
- Andreas Wetzel mickey@deadline.snafu.de
-
-
-
- Andreas Wrede andreas@planix.com
-
-
-
- Andres Vega Garcia unknown
-
-
-
- Andrew Atrens atreand@statcan.ca
-
-
-
- Andrew Gillham gillham@andrews.edu
-
-
-
- Andrew Gordon andrew.gordon@net-tel.co.uk
-
-
-
- Andrew Herbert andrew@werple.apana.org.au
-
-
-
- Andrew J. Korty ajk@purdue.edu
-
-
-
- Andrew L. Moore alm@mclink.com
-
-
-
- Andrew McRae amcrae@cisco.com
-
-
-
- Andrew Stevenson andrew@ugh.net.au
-
-
-
- Andrew Timonin tim@pool1.convey.ru
-
-
-
- Andrew V. Stesin stesin@elvisti.kiev.ua
-
-
-
- Andrew Webster awebster@dataradio.com
-
-
-
- Andrey Zakhvatov andy@icc.surw.chel.su
-
-
-
- Andy Farkas andyf@speednet.com.au
-
-
-
- Andy Valencia ajv@csd.mot.com
-
-
-
- Andy Whitcroft andy@sarc.city.ac.uk
-
-
-
- Angelo Turetta ATuretta@stylo.it
-
-
-
- Anthony C. Chavez magus@xmission.com
-
-
-
- Anthony Yee-Hang Chan yeehang@netcom.com
-
-
-
- Anton Berezin tobez@plab.ku.dk
-
-
-
- Antti Kaipila anttik@iki.fi
-
-
-
- Are Bryne are.bryne@communique.no
-
-
-
- Ari Suutari ari@suutari.iki.fi
-
-
-
- Arjan de Vet devet@IAEhv.nl
-
-
-
- Arne Henrik Juul arnej@Lise.Unit.NO
-
-
-
- Assar Westerlund assar@sics.se
-
-
-
- Atsushi Furuta furuta@sra.co.jp
-
-
-
- Atsushi Murai amurai@spec.co.jp
-
-
-
- Bakul Shah bvs@bitblocks.com
-
-
-
- Barry Bierbauch pivrnec@vszbr.cz
-
-
-
- Barry Lustig barry@ictv.com
-
-
-
- Ben Hutchinson benhutch@xfiles.org.uk
-
-
-
- Ben Jackson unknown
-
-
-
- Ben Smithurst ben@scientia.demon.co.uk
-
-
-
- Ben Walter bwalter@itachi.swcp.com
-
-
-
- Benjamin Lewis bhlewis@gte.net
-
-
-
- Bernd Rosauer br@schiele-ct.de
-
-
-
- Bill Kish kish@osf.org
-
-
-
- Bill Trost trost@cloud.rain.com
-
-
-
- Blaz Zupan blaz@amis.net
-
-
-
- Bob Van Valzah Bob@whitebarn.com
-
-
-
- Bob Willcox bob@luke.pmr.com
-
-
-
- Boris Staeblow balu@dva.in-berlin.de
-
-
-
- Boyd R. Faulkner faulkner@asgard.bga.com
-
-
-
- Brad Karp karp@eecs.harvard.edu
-
-
-
- Bradley Dunn bradley@dunn.org
-
-
-
- Brandon Gillespie brandon@roguetrader.com
-
-
-
- Bill Lloyd wlloyd@mpd.ca
-
-
-
- Bob Wilcox bob@obiwan.uucp
-
-
-
- Boyd Faulkner faulkner@mpd.tandem.com
-
-
-
- Brent J. Nordquist bjn@visi.com
-
-
-
- Brett Lymn blymn@mulga.awadi.com.AU
-
-
-
- Brett Taylor
- brett@peloton.physics.montana.edu
-
-
-
- Brian Campbell brianc@pobox.com
-
-
-
- Brian Clapper bmc@willscreek.com
-
-
-
- Brian Cully shmit@kublai.com
-
-
-
- Brian F. Feldman green@unixhelp.org
-
-
-
- Brian Handy
- handy@lambic.space.lockheed.com
-
-
-
- Brian Litzinger brian@MediaCity.com
-
-
-
- Brian McGovern bmcgover@cisco.com
-
-
-
- Brian Moore ziff@houdini.eecs.umich.edu
-
-
-
- Brian R. Haug haug@conterra.com
-
-
-
- Brian Tao taob@risc.org
-
-
-
- Brion Moss brion@queeg.com
-
-
-
- Bruce A. Mah bmah@ca.sandia.gov
-
-
-
- Bruce Albrecht bruce@zuhause.mn.org
-
-
-
- Bruce Gingery bgingery@gtcs.com
-
-
-
- Bruce J. Keeler loodvrij@gridpoint.com
-
-
-
- Bruce Murphy packrat@iinet.net.au
-
-
-
- Bruce Walter walter@fortean.com
-
-
-
- Carey Jones mcj@acquiesce.org
-
-
-
- Carl Fongheiser cmf@netins.net
-
-
-
- Carl Mascott cmascott@world.std.com
-
-
-
- Casper casper@acc.am
-
-
-
- Castor Fu castor@geocast.com
-
-
-
- Cejka Rudolf cejkar@dcse.fee.vutbr.cz
-
-
-
- Chain Lee chain@110.net
-
-
-
- Charles Hannum mycroft@ai.mit.edu
-
-
-
- Charles Henrich henrich@msu.edu
-
-
-
- Charles Mott cmott@srv.net
-
-
-
- Charles Owens owensc@enc.edu
-
-
-
- Chet Ramey chet@odin.INS.CWRU.Edu
-
-
-
- Chia-liang Kao clkao@CirX.ORG
-
-
-
- Chiharu Shibata chi@bd.mbn.or.jp
-
-
-
- Chip Norkus unknown
-
-
-
- Choi Jun Ho junker@jazz.snu.ac.kr
-
-
-
- Chris Csanady cc@tarsier.ca.sandia.gov
-
-
-
- Chris Dabrowski chris@vader.org
-
-
-
- Chris Dillon cdillon@wolves.k12.mo.us
-
-
-
- Chris Piazza cpiazza@home.net
-
-
-
- Chris Shenton
- cshenton@angst.it.hq.nasa.gov
-
-
-
- Chris Stenton jacs@gnome.co.uk
-
-
-
- Chris Timmons skynyrd@opus.cts.cwu.edu
-
-
-
- Chris Torek torek@ee.lbl.gov
-
-
-
- Christian Gusenbauer
- cg@fimp01.fim.uni-linz.ac.at
-
-
-
- Christian Haury Christian.Haury@sagem.fr
-
-
-
- Christian Weisgerber
- naddy@bigeye.rhein-neckar.de
-
-
-
- Christoph P. Kukulies kuku@FreeBSD.org
-
-
-
- Christoph Robitschko
- chmr@edvz.tu-graz.ac.at
-
-
-
- Christoph Weber-Fahr
- wefa@callcenter.systemhaus.net
-
-
-
- Christopher G. Demetriou
- cgd@postgres.berkeley.edu
-
-
-
- Christopher T. Johnson
- cjohnson@neunacht.netgsi.com
-
-
-
- Chrisy Luke chrisy@flix.net
-
-
-
- Chuck Hein chein@cisco.com
-
-
-
- Clive Lin clive@CiRX.ORG
-
-
-
- Colman Reilly careilly@tcd.ie
-
-
-
- Conrad Sabatier conrads@neosoft.com
-
-
-
- Coranth Gryphon gryphon@healer.com
-
-
-
- Cornelis van der Laan
- nils@guru.ims.uni-stuttgart.de
-
-
-
- Cove Schneider cove@brazil.nbn.com
-
-
-
- Craig Leres leres@ee.lbl.gov
-
-
-
- Craig Loomis unknown
-
-
-
- Craig Metz cmetz@inner.net
-
-
-
- Craig Spannring cts@internetcds.com
-
-
-
- Craig Struble cstruble@vt.edu
-
-
-
- Cristian Ferretti cfs@riemann.mat.puc.cl
-
-
-
- Curt Mayer curt@toad.com
-
-
-
- Cy Schubert cschuber@uumail.gov.bc.ca
-
-
-
- DI. Christian Gusenbauer
- cg@scotty.edvz.uni-linz.ac.at
-
-
-
- Dai Ishijima ishijima@tri.pref.osaka.jp
-
-
-
- Damian Hamill damian@cablenet.net
-
-
-
- Dan Cross tenser@spitfire.ecsel.psu.edu
-
-
-
- Dan Lukes dan@obluda.cz
-
-
-
- Dan Nelson dnelson@emsphone.com
-
-
-
- Dan Walters hannibal@cyberstation.net
-
-
-
- Daniel Baker dbaker@crash.ops.neosoft.com
-
-
-
- Daniel M. Eischen
- deischen@iworks.InterWorks.org
-
-
-
- Daniel O'Connor doconnor@gsoft.com.au
-
-
-
- Daniel Poirot poirot@aio.jsc.nasa.gov
-
-
-
- Daniel Rock rock@cs.uni-sb.de
-
-
-
- Danny Egen unknown
-
-
-
- Danny J. Zerkel dzerkel@phofarm.com
-
-
-
- Darren Reed avalon@coombs.anu.edu.au
-
-
-
- Dave Adkins adkin003@tc.umn.edu
-
-
-
- Dave Andersen angio@aros.net
-
-
-
- Dave Blizzard dblizzar@sprynet.com
-
-
-
- Dave Bodenstab imdave@synet.net
-
-
-
- Dave Burgess burgess@hrd769.brooks.af.mil
-
-
-
- Dave Chapeskie dchapes@ddm.on.ca
-
-
-
- Dave Cornejo dave@dogwood.com
-
-
-
- Dave Edmondson davided@sco.com
-
-
-
- Dave Glowacki dglo@ssec.wisc.edu
-
-
-
- Dave Marquardt marquard@austin.ibm.com
-
-
-
- Dave Tweten tweten@FreeBSD.org
-
-
-
- David A. Adkins adkin003@tc.umn.edu
-
-
-
- David A. Bader dbader@umiacs.umd.edu
-
-
-
- David Borman dab@bsdi.com
-
-
-
- David Dawes dawes@XFree86.org
-
-
-
- David Filo filo@yahoo.com
-
-
-
- David Holland dholland@eecs.harvard.edu
-
-
-
- David Holloway daveh@gwythaint.tamis.com
-
-
-
- David Horwitt dhorwitt@ucsd.edu
-
-
-
- David Hovemeyer daveho@infocom.com
-
-
-
- David Jones dej@qpoint.torfree.net
-
-
-
- David Kelly dkelly@tomcat1.tbe.com
-
-
-
- David Kulp dkulp@neomorphic.com
-
-
-
- David L. Nugent davidn@blaze.net.au
-
-
-
- David Leonard d@scry.dstc.edu.au
-
-
-
- David Malone dwmalone@maths.tcd.ie
-
-
-
- David Muir Sharnoff muir@idiom.com
-
-
-
- David S. Miller davem@jenolan.rutgers.edu
-
-
-
- David Wolfskill dhw@whistle.com
-
-
-
- Dean Gaudet dgaudet@arctic.org
-
-
-
- Dean Huxley dean@fsa.ca
-
-
-
- Denis Fortin unknown
-
-
-
- Dennis Glatting
- dennis.glatting@software-munitions.com
-
-
-
- Denton Gentry denny1@home.com
-
-
-
- Derek Inksetter derek@saidev.com
-
-
-
- Dima Sivachenko dima@Chg.RU
-
-
-
- Dirk Keunecke dk@panda.rhein-main.de
-
-
-
- Dirk Nehrling nerle@pdv.de
-
-
-
- Dmitry Khrustalev dima@xyzzy.machaon.ru
-
-
-
- Dmitry Kohmanyuk dk@farm.org
-
-
-
- Dom Mitchell dom@myrddin.demon.co.uk
-
-
-
- Don Croyle croyle@gelemna.ft-wayne.in.us
-
-
-
- &a.whiteside;
-
-
-
- Don Morrison dmorrisn@u.washington.edu
-
-
-
- Don Yuniskis dgy@rtd.com
-
-
-
- Donald Maddox dmaddox@conterra.com
-
-
-
- Doug Barton studded@dal.net
-
-
-
- Douglas Ambrisko ambrisko@whistle.com
-
-
-
- Douglas Carmichael dcarmich@mcs.com
-
-
-
- Douglas Crosher dtc@scrooge.ee.swin.oz.au
-
-
-
- Drew Derbyshire ahd@kew.com
-
-
-
- Duncan Barclay dmlb@ragnet.demon.co.uk
-
-
-
- Dustin Sallings dustin@spy.net
-
-
-
- Eckart "Isegrim" Hofmann
- Isegrim@Wunder-Nett.org
-
-
-
- Ed Gold
- vegold01@starbase.spd.louisville.edu
-
-
-
- Ed Hudson elh@p5.spnet.com
-
-
-
- Edward Wang edward@edcom.com
-
-
-
- Edwin Groothus edwin@nwm.wan.philips.com
-
-
-
- Eiji-usagi-MATSUmoto usagi@clave.gr.jp
-
-
-
- ELISA Font Project
-
-
-
- Elmar Bartel
- bartel@informatik.tu-muenchen.de
-
-
-
- Eric A. Griff eagriff@global2000.net
-
-
-
- Eric Blood eblood@cs.unr.edu
-
-
-
- Eric J. Haug ejh@slustl.slu.edu
-
-
-
- Eric J. Schwertfeger eric@cybernut.com
-
-
-
- Eric L. Hernes erich@lodgenet.com
-
-
-
- Eric P. Scott eps@sirius.com
-
-
-
- Eric Sprinkle eric@ennovatenetworks.com
-
-
-
- Erich Stefan Boleyn erich@uruk.org
-
-
-
- Erik E. Rantapaa rantapaa@math.umn.edu
-
-
-
- Erik H. Moe ehm@cris.com
-
-
-
- Ernst Winter ewinter@lobo.muc.de
-
-
-
- Eugene M. Kim astralblue@usa.net
-
-
-
- Eugene Radchenko genie@qsar.chem.msu.su
-
-
-
- Evan Champion evanc@synapse.net
-
-
-
- Faried Nawaz fn@Hungry.COM
-
-
-
- Flemming Jacobsen fj@tfs.com
-
-
-
- Fong-Ching Liaw fong@juniper.net
-
-
-
- Francis M J Hsieh mjshieh@life.nthu.edu.tw
-
-
-
- Frank Bartels knarf@camelot.de
-
-
-
- Frank Chen Hsiung Chan
- frankch@waru.life.nthu.edu.tw
-
-
-
- Frank Durda IV uhclem@nemesis.lonestar.org
-
-
-
- Frank MacLachlan fpm@n2.net
-
-
-
- Frank Nobis fn@Radio-do.de
-
-
-
- Frank Volf volf@oasis.IAEhv.nl
-
-
-
- Frank ten Wolde franky@pinewood.nl
-
-
-
- Frank van der Linden frank@fwi.uva.nl
-
-
-
- Fred Cawthorne fcawth@jjarray.umn.edu
-
-
-
- Fred Gilham gilham@csl.sri.com
-
-
-
- Fred Templin templin@erg.sri.com
-
-
-
- Frederick Earl Gray fgray@rice.edu
-
-
-
- FUJIMOTO Kensaku
- fujimoto@oscar.elec.waseda.ac.jp
-
-
-
- FUJISHIMA Satsuki k5@respo.or.jp
-
-
-
- FURUSAWA Kazuhisa
- furusawa@com.cs.osakafu-u.ac.jp
-
-
-
- Gabor Kincses gabor@acm.org
-
-
-
- Gabor Zahemszky zgabor@CoDe.hu
-
-
-
- Garance A Drosehn gad@eclipse.its.rpi.edu
-
-
-
- Gareth McCaughan gjm11@dpmms.cam.ac.uk
-
-
-
- Gary A. Browning gab10@griffcd.amdahl.com
-
-
-
- Gary Howland gary@hotlava.com
-
-
-
- Gary J. garyj@rks32.pcs.dec.com
-
-
-
- Gary Kline kline@thought.org
-
-
-
- Gaspar Chilingarov nightmar@lemming.acc.am
-
-
-
- Gea-Suan Lin gsl@tpts4.seed.net.tw
-
-
-
- Geoff Rehmet csgr@alpha.ru.ac.za
-
-
-
- Georg Wagner georg.wagner@ubs.com
-
-
-
- Gerard Roudier groudier@club-internet.fr
-
-
-
- Gianmarco Giovannelli
- gmarco@giovannelli.it
-
-
-
- Gil Kloepfer Jr. gil@limbic.ssdl.com
-
-
-
- Gilad Rom rom_glsa@ein-hashofet.co.il
-
-
-
- Ginga Kawaguti
- ginga@amalthea.phys.s.u-tokyo.ac.jp
-
-
-
- Giles Lean giles@nemeton.com.au
-
-
-
- Glen Foster gfoster@gfoster.com
-
-
-
- Glenn Johnson gljohns@bellsouth.net
-
-
-
- Godmar Back gback@facility.cs.utah.edu
-
-
-
- Goran Hammarback goran@astro.uu.se
-
-
-
- Gord Matzigkeit gord@enci.ucalgary.ca
-
-
-
- Graham Wheeler gram@cdsec.com
-
-
-
- Greg A. Woods woods@zeus.leitch.com
-
-
-
- Greg Ansley gja@ansley.com
-
-
-
- Greg Troxel gdt@ir.bbn.com
-
-
-
- Greg Ungerer gerg@stallion.oz.au
-
-
-
- Gregory Bond gnb@itga.com.au
-
-
-
- Gregory D. Moncreaff
- moncrg@bt340707.res.ray.com
-
-
-
- Guy Harris guy@netapp.com
-
-
-
- Guy Helmer ghelmer@cs.iastate.edu
-
-
-
- HAMADA Naoki hamada@astec.co.jp
-
-
-
- HONDA Yasuhiro
- honda@kashio.info.mie-u.ac.jp
-
-
-
- HOSOBUCHI Noriyuki hoso@buchi.tama.or.jp
-
-
-
- Hannu Savolainen hannu@voxware.pp.fi
-
-
-
- Hans Huebner hans@artcom.de
-
-
-
- Hans Petter Bieker zerium@webindex.no
-
-
-
- Hans Zuidam hans@brandinnovators.com
-
-
-
- Harlan Stenn Harlan.Stenn@pfcs.com
-
-
-
- Harold Barker hbarker@dsms.com
-
-
-
- Havard Eidnes
- Havard.Eidnes@runit.sintef.no
-
-
-
- Heikki Suonsivu hsu@cs.hut.fi
-
-
-
- Heiko W. Rupp unknown
-
-
-
- Helmut F. Wirth hfwirth@ping.at
-
-
-
- Henrik Vestergaard Draboel
- hvd@terry.ping.dk
-
-
-
- Herb Peyerl hpeyerl@NetBSD.org
-
-
-
- Hideaki Ohmon ohmon@tom.sfc.keio.ac.jp
-
-
-
- Hidekazu Kuroki hidekazu@cs.titech.ac.jp
-
-
-
- Hideki Yamamoto hyama@acm.org
-
-
-
- Hidetoshi Shimokawa
- simokawa@sat.t.u-tokyo.ac.jp
-
-
-
- Hideyuki Suzuki
- hideyuki@sat.t.u-tokyo.ac.jp
-
-
-
- Hirayama Issei iss@mail.wbs.ne.jp
-
-
-
- Hiroaki Sakai sakai@miya.ee.kagu.sut.ac.jp
-
-
-
- Hiroharu Tamaru tamaru@ap.t.u-tokyo.ac.jp
-
-
-
- Hironori Ikura hikura@kaisei.org
-
-
-
- Hiroshi Nishikawa nis@pluto.dti.ne.jp
-
-
-
- Hiroya Tsubakimoto unknown
-
-
-
- Hiroyuki NAKAJI
- nakaji@zeisei3.dpri.kyoto-u.ac.jp
-
-
-
- Holger Veit Holger.Veit@gmd.de
-
-
-
- Holm Tiffe holm@geophysik.tu-freiberg.de
-
-
-
- Horance Chou
- horance@freedom.ie.cycu.edu.tw
-
-
-
- Horihiro Kumagaio kuma@jp.freebsd.org
-
-
-
- Horikawa Kazuo k-horik@mail.yk.rim.or.jp
-
-
-
- Hr.Ladavac lada@ws2301.gud.siemens.co.at
-
-
-
- Hubert Feyrer hubertf@NetBSD.ORG
-
-
-
- Hugh F. Mahon hugh@nsmdserv.cnd.hp.com
-
-
-
- Hugh Mahon h_mahon@fc.hp.com
-
-
-
- Hung-Chi Chu hcchu@r350.ee.ntu.edu.tw
-
-
-
- IMAI Takeshi take-i@ceres.dti.ne.jp
-
-
-
- IMAMURA Tomoaki
- tomoak-i@is.aist-nara.ac.jp
-
-
-
- Ian Dowse iedowse@maths.tcd.ie
-
-
-
- Ian Holland ianh@tortuga.com.au
-
-
-
- Ian Struble ian@broken.net
-
-
-
- Ian Vaudrey i.vaudrey@bigfoot.com
-
-
-
- Igor Khasilev igor@jabber.paco.odessa.ua
-
-
-
- Igor Roshchin str@giganda.komkon.org
-
-
-
- Igor Sviridov siac@ua.net
-
-
-
- Igor Vinokurov igor@zynaps.ru
-
-
-
- Ikuo Nakagawa ikuo@isl.intec.co.jp
-
-
-
- Ilya V. Komarov mur@lynx.ru
-
-
-
- Issei Suzuki issei@jp.FreeBSD.org
-
-
-
- Itsuro Saito saito@miv.t.u-tokyo.ac.jp
-
-
-
- J. Bryant jbryant@argus.flash.net
-
-
-
- J. David Lowe lowe@saturn5.com
-
-
-
- J. Han hjh@best.com
-
-
-
- J. Hawk jhawk@MIT.EDU
-
-
-
- J.T. Conklin jtc@cygnus.com
-
-
-
- J.T. Jang keith@email.gcn.net.tw
-
-
-
- Jack jack@zeus.xtalwind.net
-
-
-
- Jacob Bohn Lorensen jacob@jblhome.ping.mk
-
-
-
- Jagane D Sundar jagane@netcom.com
-
-
-
- Jake Hamby jehamby@lightside.com
-
-
-
- James Clark jjc@jclark.com
-
-
-
- James D. Stewart jds@c4systm.com
-
-
-
- James Jegers jimj@miller.cs.uwm.edu
-
-
-
- James Raynard
- fhackers@jraynard.demon.co.uk
-
-
-
- James T. Liu jtliu@phlebas.rockefeller.edu
-
-
-
- James da Silva jds@cs.umd.edu
-
-
-
- Jan Conard
- charly@fachschaften.tu-muenchen.de
-
-
-
- Jan Koum jkb@FreeBSD.org
-
-
-
- Janick Taillandier
- Janick.Taillandier@ratp.fr
-
-
-
- Janusz Kokot janek@gaja.ipan.lublin.pl
-
-
-
- Jarle Greipsland jarle@idt.unit.no
-
-
-
- Jason Garman init@risen.org
-
-
-
- Jason Thorpe thorpej@NetBSD.org
-
-
-
- Jason Wright jason@OpenBSD.org
-
-
-
- Jason Young
- doogie@forbidden-donut.anet-stl.com
-
-
-
- Javier Martin Rueda jmrueda@diatel.upm.es
-
-
-
- Jay Fenlason hack@datacube.com
-
-
-
- Jaye Mathisen mrcpu@cdsnet.net
-
-
-
- Jeff Bartig jeffb@doit.wisc.edu
-
-
-
- Jeff Forys jeff@forys.cranbury.nj.us
-
-
-
- Jeff Kletsky Jeff@Wagsky.com
-
-
-
- Jeffrey Evans evans@scnc.k12.mi.us
-
-
-
- Jeffrey Wheat jeff@cetlink.net
-
-
-
- Jens Schweikhardt
- schweikh@ito.uni-stuttgart.de
-
-
-
- Jeremy Allison jallison@whistle.com
-
-
-
- Jeremy Chatfield jdc@xinside.com
-
-
-
- Jeremy Lea reg@shale.csir.co.za
-
-
-
- Jeremy Prior unknown
-
-
-
- Jeroen Ruigrok/Asmodai asmodai@wxs.nl
-
-
-
- Jesse Rosenstock jmr@ugcs.caltech.edu
-
-
-
- Jian-Da Li jdli@csie.nctu.edu.tw
-
-
-
- Jim Babb babb@FreeBSD.org
-
-
-
- Jim Binkley jrb@cs.pdx.edu
-
-
-
- Jim Carroll jim@carroll.com
-
-
-
- Jim Flowers jflowers@ezo.net
-
-
-
- Jim Leppek jleppek@harris.com
-
-
-
- Jim Lowe james@cs.uwm.edu
-
-
-
- Jim Mattson jmattson@sonic.net
-
-
-
- Jim Mercer jim@komodo.reptiles.org
-
-
-
- Jim Mock jim@phrantic.phear.net
-
-
-
- Jim Wilson wilson@moria.cygnus.com
-
-
-
- Jimbo Bahooli
- griffin@blackhole.iceworld.org
-
-
-
- Jin Guojun jin@george.lbl.gov
-
-
-
- Joachim Kuebart unknown
-
-
-
- Joao Carlos Mendes Luis jonny@jonny.eng.br
-
-
-
- Jochen Pohl jpo.drs@sni.de
-
-
-
- Joe "Marcus" Clarke marcus@miami.edu
-
-
-
- Joe Abley jabley@clear.co.nz
-
-
-
- Joe Jih-Shian Lu jslu@dns.ntu.edu.tw
-
-
-
- Joe Orthoefer j_orthoefer@tia.net
-
-
-
- Joe Traister traister@mojozone.org
-
-
-
- Joel Faedi Joel.Faedi@esial.u-nancy.fr
-
-
-
- Joel Ray Holveck joelh@gnu.org
-
-
-
- Joel Sutton sutton@aardvark.apana.org.au
-
-
-
- Johan Granlund johan@granlund.nu
-
-
-
- Johan Karlsson k@numeri.campus.luth.se
-
-
-
- Johan Larsson johan@moon.campus.luth.se
-
-
-
- Johann Tonsing jtonsing@mikom.csir.co.za
-
-
-
- Johannes Helander unknown
-
-
-
- Johannes Stille unknown
-
-
-
- John Baldwin jobaldwi@vt.edu
-
-
-
- John Beckett jbeckett@southern.edu
-
-
-
- John Beukema jbeukema@hk.super.net
-
-
-
- John Brezak unknown
-
-
-
- John Capo jc@irbs.com
-
-
-
- John F. Woods jfw@jfwhome.funhouse.com
-
-
-
- John Goerzen
- jgoerzen@alexanderwohl.complete.org
-
-
-
- John Hay jhay@mikom.csir.co.za
-
-
-
- John Heidemann johnh@isi.edu
-
-
-
- John Hood cgull@owl.org
-
-
-
- John Kohl unknown
-
-
-
- John Lind john@starfire.mn.org
-
-
-
- John Mackin john@physiol.su.oz.au
-
-
-
- John P johnp@lodgenet.com
-
-
-
- John Perry perry@vishnu.alias.net
-
-
-
- John Preisler john@vapornet.com
-
-
-
- John Rochester jr@cs.mun.ca
-
-
-
- John Sadler john_sadler@alum.mit.edu
-
-
-
- John Saunders john@pacer.nlc.net.au
-
-
-
- John W. DeBoskey jwd@unx.sas.com
-
-
-
- John Wehle john@feith.com
-
-
-
- John Woods jfw@eddie.mit.edu
-
-
-
- Jon Morgan morgan@terminus.trailblazer.com
-
-
-
- Jonathan H N Chin jc254@newton.cam.ac.uk
-
-
-
- Jonathan Hanna
- jh@pc-21490.bc.rogers.wave.ca
-
-
-
- Jorge Goncalves j@bug.fe.up.pt
-
-
-
- Jorge M. Goncalves ee96199@tom.fe.up.pt
-
-
-
- Jos Backus jbackus@plex.nl
-
-
-
- Jose M. Alcaide jose@we.lc.ehu.es
-
-
-
- Josef Grosch
- jgrosch@superior.mooseriver.com
-
-
-
- Josef Karthauser joe@uk.freebsd.org
-
-
-
- Joseph Stein joes@seaport.net
-
-
-
- Josh Gilliam josh@quick.net
-
-
-
- Josh Tiefenbach josh@ican.net
-
-
-
- Juergen Lock nox@jelal.hb.north.de
-
-
-
- Juha Inkari inkari@cc.hut.fi
-
-
-
- Jukka A. Ukkonen jua@iki.fi
-
-
-
- Julian Assange proff@suburbia.net
-
-
-
- Julian Coleman j.d.coleman@ncl.ac.uk
-
-
-
- Julian H. Stacey jhs@freebsd.org
-
-
-
- Julian Jenkins kaveman@magna.com.au
-
-
-
- Junichi Satoh junichi@jp.freebsd.org
-
-
-
- Junji SAKAI sakai@jp.freebsd.org
-
-
-
- Junya WATANABE junya-w@remus.dti.ne.jp
-
-
-
- K.Higashino a00303@cc.hc.keio.ac.jp
-
-
-
- KUNISHIMA Takeo kunishi@c.oka-pu.ac.jp
-
-
-
- Kai Vorma vode@snakemail.hut.fi
-
-
-
- Kaleb S. Keithley kaleb@ics.com
-
-
-
- Kaneda Hiloshi vanitas@ma3.seikyou.ne.jp
-
-
-
- Kapil Chowksey kchowksey@hss.hns.com
-
-
-
- Karl Denninger karl@mcs.com
-
-
-
- Karl Dietz Karl.Dietz@triplan.com
-
-
-
- Karl Lehenbauer karl@NeoSoft.com
-
-
-
- Kato Takenori
- kato@eclogite.eps.nagoya-u.ac.jp
-
-
-
- Kauzo Horikawa h-horik@yk.rim.or.jp
-
-
-
- Kawanobe Koh kawanobe@st.rim.or.jp
-
-
-
- Kazuhiko Kiriyama kiri@kiri.toba-cmt.ac.jp
-
-
-
- Kazuo Horikawa horikawa@jp.FreeBSD.org
-
-
-
- Kees Jan Koster kjk1@ukc.ac.uk
-
-
-
- Keith Bostic bostic@bostic.com
-
-
-
- Keith E. Walker unknown
-
-
-
- Keith Moore unknown
-
-
-
- Keith Sklower unknown
-
-
-
- Ken Hornstein unknown
-
-
-
- Ken Key key@cs.utk.edu
-
-
-
- Ken Mayer kmayer@freegate.com
-
-
-
- Kenji Saito marukun@mx2.nisiq.net
-
-
-
- Kenji Tomita tommyk@da2.so-net.or.jp
-
-
-
- Kenneth Furge kenneth.furge@us.endress.com
-
-
-
- Kenneth Monville desmo@bandwidth.org
-
-
-
- Kenneth R. Westerback krw@tcn.net
-
-
-
- Kenneth Stailey kstailey@gnu.ai.mit.edu
-
-
-
- Kent Talarico kent@shipwreck.tsoft.net
-
-
-
- Kent Vander Velden graphix@iastate.edu
-
-
-
- Kentaro Inagaki JBD01226@niftyserve.ne.jp
-
-
-
- Kevin Bracey kbracey@art.acorn.co.uk
-
-
-
- Kevin Day toasty@dragondata.com
-
-
-
- Kevin Lahey kml@nas.nasa.gov
-
-
-
- Kevin Street street@iname.com
-
-
-
- Kevin Van Maren vanmaren@fast.cs.utah.edu
-
-
-
- Kiroh HARADA kiroh@kh.rim.or.jp
-
-
-
- Klaus Klein kleink@layla.inka.de
-
-
-
- Klaus-J. Wolf Yanestra@t-online.de
-
-
-
- Koichi Sato copan@ppp.fastnet.or.jp
-
-
-
- Kostya Lukin lukin@okbmei.msk.su
-
-
-
- Kouichi Hirabayashi kh@mogami-wire.co.jp
-
-
-
- Kurt D. Zeilenga Kurt@Boolean.NET
-
-
-
- Kurt Olsen kurto@tiny.mcs.usu.edu
-
-
-
- L. Jonas Olsson
- ljo@ljo-slip.DIALIN.CWRU.Edu
-
-
-
- Lars Köller
- Lars.Koeller@Uni-Bielefeld.DE
-
-
-
- Larry Altneu larry@ALR.COM
-
-
-
- Laurence Lopez lopez@mv.mv.com
-
-
-
- Lee Cremeans lcremean@tidalwave.net
-
-
-
- Liang Tai-hwa
- avatar@www.mmlab.cse.yzu.edu.tw
-
-
-
- Lon Willett lon%softt.uucp@math.utah.edu
-
-
-
- Louis A. Mamakos louie@TransSys.COM
-
-
-
- Louis Mamakos loiue@TransSys.com
-
-
-
- Lucas James Lucas.James@ldjpc.apana.org.au
-
-
-
- Lyndon Nerenberg lyndon@orthanc.com
-
-
-
- M.C. Wong unknown
-
-
-
- MANTANI Nobutaka nobutaka@nobutaka.com
-
-
-
- MIHIRA Sanpei Yoshiro sanpei@sanpei.org
-
-
-
- MITA Yoshio mita@jp.FreeBSD.ORG
-
-
-
- MITSUNAGA Noriaki
- mitchy@er.ams.eng.osaka-u.ac.jp
-
-
-
- MOROHOSHI Akihiko moro@race.u-tokyo.ac.jp
-
-
-
- Magnus Enbom dot@tinto.campus.luth.se
-
-
-
- Mahesh Neelakanta mahesh@gcomm.com
-
-
-
- Makoto MATSUSHITA matusita@jp.freebsd.org
-
-
-
- Makoto WATANABE
- watanabe@zlab.phys.nagoya-u.ac.jp
-
-
-
- Malte Lance malte.lance@gmx.net
-
-
-
- Manu Iyengar
- iyengar@grunthos.pscwa.psca.com
-
-
-
- Marc Frajola marc@dev.com
-
-
-
- Marc Ramirez mrami@mramirez.sy.yale.edu
-
-
-
- Marc Slemko marcs@znep.com
-
-
-
- Marc van Kempen wmbfmk@urc.tue.nl
-
-
-
- Marcel Moolenaar marcel@scc.nl
-
-
-
- Mario Sergio Fujikawa Ferreira
- lioux@gns.com.br
-
-
-
- Mark Andrews unknown
-
-
-
- Mark Cammidge mark@gmtunx.ee.uct.ac.za
-
-
-
- Mark Diekhans markd@grizzly.com
-
-
-
- Mark Huizer xaa@stack.nl
-
-
-
- Mark J. Taylor mtaylor@cybernet.com
-
-
-
- Mark Krentel krentel@rice.edu
-
-
-
- Mark Mayo markm@vmunix.com
-
-
-
- Mark Thompson thompson@tgsoft.com
-
-
-
- Mark Tinguely tinguely@plains.nodak.edu
-
-
-
- Mark Treacy unknown
-
-
-
- Mark Valentine mark@linus.demon.co.uk
-
-
-
- Martin Birgmeier
-
-
-
- Martin Ibert mib@ppe.bb-data.de
-
-
-
- Martin Kammerhofer dada@sbox.tu-graz.ac.at
-
-
-
- Martin Renters martin@tdc.on.ca
-
-
-
- Martti Kuparinen
- erakupa@kk.etx.ericsson.se
-
-
-
- Masachika ISHIZUKA
- ishizuka@isis.min.ntt.jp
-
-
-
- Mas.TAKEMURA unknown
-
-
-
- Masafumi NAKANE max@wide.ad.jp
-
-
-
- Masahiro Sekiguchi
- seki@sysrap.cs.fujitsu.co.jp
-
-
-
- Masanobu Saitoh msaitoh@spa.is.uec.ac.jp
-
-
-
- Masanori Kanaoka kana@saijo.mke.mei.co.jp
-
-
-
- Masanori Kiriake seiken@ncs.co.jp
-
-
-
- Masatoshi TAMURA
- tamrin@shinzan.kuee.kyoto-u.ac.jp
-
-
-
- Mats Lofkvist mal@algonet.se
-
-
-
- Matt Bartley mbartley@lear35.cytex.com
-
-
-
- Matt Thomas matt@3am-software.com
-
-
-
- Matt White mwhite+@CMU.EDU
-
-
-
- Matthew C. Mead mmead@Glock.COM
-
-
-
- Matthew Cashdollar mattc@rfcnet.com
-
-
-
- Matthew Flatt mflatt@cs.rice.edu
-
-
-
- Matthew Fuller fullermd@futuresouth.com
-
-
-
- Matthew N. Dodd winter@jurai.net
-
-
-
- Matthew Stein matt@bdd.net
-
-
-
- Matthias Pfaller leo@dachau.marco.de
-
-
-
- Matthias Scheler tron@netbsd.org
-
-
-
- Mattias Gronlund
- Mattias.Gronlund@sa.erisoft.se
-
-
-
- Mattias Pantzare pantzer@ludd.luth.se
-
-
-
- Maurice Castro
- maurice@planet.serc.rmit.edu.au
-
-
-
- Max Euston meuston@jmrodgers.com
-
-
-
- Max Khon fjoe@husky.iclub.nsu.ru
-
-
-
- Maxim Bolotin max@rsu.ru
-
-
-
- Micha Class
- michael_class@hpbbse.bbn.hp.com
-
-
-
- Michael Butler imb@scgt.oz.au
-
-
-
- Michael Butschky butsch@computi.erols.com
-
-
-
- Michael Clay mclay@weareb.org
-
-
-
- Michael Elbel me@FreeBSD.ORG
-
-
-
- Michael Galassi nerd@percival.rain.com
-
-
-
- Michael Hancock michaelh@cet.co.jp
-
-
-
- Michael Hohmuth hohmuth@inf.tu-dresden.de
-
-
-
- Michael Perlman canuck@caam.rice.edu
-
-
-
- Michael Petry petry@netwolf.NetMasters.com
-
-
-
- Michael Reifenberger root@totum.plaut.de
-
-
-
- Michael Searle searle@longacre.demon.co.uk
-
-
-
- Michal Listos mcl@Amnesiac.123.org
-
-
-
- Michio Karl Jinbo
- karl@marcer.nagaokaut.ac.jp
-
-
-
- Miguel Angel Sagreras
- msagre@cactus.fi.uba.ar
-
-
-
- Mihoko Tanaka m_tonaka@pa.yokogawa.co.jp
-
-
-
- Mika Nystrom mika@cs.caltech.edu
-
-
-
- Mikael Hybsch micke@dynas.se
-
-
-
- Mikael Karpberg
- karpen@ocean.campus.luth.se
-
-
-
- Mike Del repenting@hotmail.com
-
-
-
- Mike Durian durian@plutotech.com
-
-
-
- Mike Durkin mdurkin@tsoft.sf-bay.org
-
-
-
- Mike E. Matsnev mike@azog.cs.msu.su
-
-
-
- Mike Evans mevans@candle.com
-
-
-
- Mike Grupenhoff kashmir@umiacs.umd.edu
-
-
-
- Mike Hibler mike@marker.cs.utah.edu
-
-
-
- Mike Karels unknown
-
-
-
- Mike McGaughey mmcg@cs.monash.edu.au
-
-
-
- Mike Meyer mwm@shiva.the-park.com
-
-
-
- Mike Mitchell mitchell@ref.tfs.com
-
-
-
- Mike Murphy mrm@alpharel.com
-
-
-
- Mike Peck mike@binghamton.edu
-
-
-
- Mike Spengler mks@msc.edu
-
-
-
- Mikhail A. Sokolov mishania@demos.su
-
-
-
- Mikhail Teterin mi@aldan.ziplink.net
-
-
-
- Ming-I Hseh PA@FreeBSD.ee.Ntu.edu.TW
-
-
-
- Mitsuru IWASAKI iwasaki@pc.jaring.my
-
-
-
- Monte Mitzelfelt monte@gonefishing.org
-
-
-
- Morgan Davis root@io.cts.com
-
-
-
- Mostyn Lewis mostyn@mrl.com
-
-
-
- Motoyuki Kasahara m-kasahr@sra.co.jp
-
-
-
- Motoyuki Konno motoyuki@snipe.rim.or.jp
-
-
-
- Munechika Sumikawa sumikawa@kame.net
-
-
-
- Murray Stokely murray@cdrom.com
-
-
-
- N.G.Smith ngs@sesame.hensa.ac.uk
-
-
-
- NAGAO Tadaaki nagao@cs.titech.ac.jp
-
-
-
- NAKAJI Hiroyuki
- nakaji@zeisei.dpri.kyoto-u.ac.jp
-
-
-
- NAKAMURA Kazushi nkazushi@highway.or.jp
-
-
-
- NAKAMURA Motonori
- motonori@econ.kyoto-u.ac.jp
-
-
-
- NIIMI Satoshi sa2c@and.or.jp
-
-
-
- NOKUBI Hirotaka h-nokubi@yyy.or.jp
-
-
-
- Nadav Eiron nadav@barcode.co.il
-
-
-
- Nanbor Wang nw1@cs.wustl.edu
-
-
-
- Naofumi Honda
- honda@Kururu.math.sci.hokudai.ac.jp
-
-
-
- Naoki Hamada nao@tom-yam.or.jp
-
-
-
- Narvi narvi@haldjas.folklore.ee
-
-
-
- Nathan Dorfman nathan@rtfm.net
-
-
-
- Neal Fachan kneel@ishiboo.com
-
-
-
- Neil Blakey-Milner nbm@rucus.ru.ac.za
-
-
-
- Niall Smart rotel@indigo.ie
-
-
-
- Nick Barnes Nick.Barnes@pobox.com
-
-
-
- Nick Handel nhandel@NeoSoft.com
-
-
-
- Nick Hilliard nick@foobar.org
-
-
-
- Nick Sayer nsayer@quack.kfu.com
-
-
-
- Nick Williams njw@cs.city.ac.uk
-
-
-
- Nickolay N. Dudorov nnd@itfs.nsk.su
-
-
-
- Niklas Hallqvist niklas@filippa.appli.se
-
-
-
- Nisha Talagala nisha@cs.berkeley.edu
-
-
-
- No Name ZW6T-KND@j.asahi-net.or.jp
-
-
-
- No Name adrian@virginia.edu
-
-
-
- No Name alex@elvisti.kiev.ua
-
-
-
- No Name anto@netscape.net
-
-
-
- No Name bobson@egg.ics.nitch.ac.jp
-
-
-
- No Name bovynf@awe.be
-
-
-
- No Name burg@is.ge.com
-
-
-
- No Name chris@gnome.co.uk
-
-
-
- No Name colsen@usa.net
-
-
-
- No Name coredump@nervosa.com
-
-
-
- No Name dannyman@arh0300.urh.uiuc.edu
-
-
-
- No Name davids@SECNET.COM
-
-
-
- No Name derek@free.org
-
-
-
- No Name devet@adv.IAEhv.nl
-
-
-
- No Name djv@bedford.net
-
-
-
- No Name dvv@sprint.net
-
-
-
- No Name enami@ba2.so-net.or.jp
-
-
-
- No Name flash@eru.tubank.msk.su
-
-
-
- No Name flash@hway.ru
-
-
-
- No Name fn@pain.csrv.uidaho.edu
-
-
-
- No Name gclarkii@netport.neosoft.com
-
-
-
- No Name gordon@sheaky.lonestar.org
-
-
-
- No Name graaf@iae.nl
-
-
-
- No Name greg@greg.rim.or.jp
-
-
-
- No Name grossman@cygnus.com
-
-
-
- No Name gusw@fub46.zedat.fu-berlin.de
-
-
-
- No Name hfir@math.rochester.edu
-
-
-
- No Name hnokubi@yyy.or.jp
-
-
-
- No Name iaint@css.tuu.utas.edu.au
-
-
-
- No Name invis@visi.com
-
-
-
- No Name ishisone@sra.co.jp
-
-
-
- No Name iverson@lionheart.com
-
-
-
- No Name jpt@magic.net
-
-
-
- No Name junker@jazz.snu.ac.kr
-
-
-
- No Name k-sugyou@ccs.mt.nec.co.jp
-
-
-
- No Name kenji@reseau.toyonaka.osaka.jp
-
-
-
- No Name kfurge@worldnet.att.net
-
-
-
- No Name lh@aus.org
-
-
-
- No Name lhecking@nmrc.ucc.ie
-
-
-
- No Name mrgreen@mame.mu.oz.au
-
-
-
- No Name nakagawa@jp.freebsd.org
-
-
-
- No Name ohki@gssm.otsuka.tsukuba.ac.jp
-
-
-
- No Name owaki@st.rim.or.jp
-
-
-
- No Name pechter@shell.monmouth.com
-
-
-
- No Name pete@pelican.pelican.com
-
-
-
- No Name pritc003@maroon.tc.umn.edu
-
-
-
- No Name risner@stdio.com
-
-
-
- No Name roman@rpd.univ.kiev.ua
-
-
-
- No Name root@ns2.redline.ru
-
-
-
- No Name root@uglabgw.ug.cs.sunysb.edu
-
-
-
- No Name stephen.ma@jtec.com.au
-
-
-
- No Name sumii@is.s.u-tokyo.ac.jp
-
-
-
- No Name takas-su@is.aist-nara.ac.jp
-
-
-
- No Name tamone@eig.unige.ch
-
-
-
- No Name tjevans@raleigh.ibm.com
-
-
-
- No Name tony-o@iij.ad.jp amurai@spec.co.jp
-
-
-
- No Name torii@tcd.hitachi.co.jp
-
-
-
- No Name uenami@imasy.or.jp
-
-
-
- No Name uhlar@netlab.sk
-
-
-
- No Name vode@hut.fi
-
-
-
- No Name wlloyd@mpd.ca
-
-
-
- No Name wlr@furball.wellsfargo.com
-
-
-
- No Name wmbfmk@urc.tue.nl
-
-
-
- No Name yamagata@nwgpc.kek.jp
-
-
-
- No Name ziggy@ryan.org
-
-
-
- Nobuhiro Yasutomi nobu@psrc.isac.co.jp
-
-
-
- Nobuyuki Koganemaru
- kogane@koganemaru.co.jp
-
-
-
- Norio Suzuki nosuzuki@e-mail.ne.jp
-
-
-
- Noritaka Ishizumi graphite@jp.FreeBSD.ORG
-
-
-
- Noriyuki Soda soda@sra.co.jp
-
-
-
- Olaf Wagner wagner@luthien.in-berlin.de
-
-
-
- Oleg Sharoiko os@rsu.ru
-
-
-
- Oliver Breuninger ob@seicom.NET
-
-
-
- Oliver Friedrichs oliver@secnet.com
-
-
-
- Oliver Fromme
- oliver.fromme@heim3.tu-clausthal.de
-
-
-
- Oliver Laumann
- net@informatik.uni-bremen.de
-
-
-
- Oliver Oberdorf oly@world.std.com
-
-
-
- Olof Johansson offe@ludd.luth.se
-
-
-
- Osokin Sergey aka oZZ ozz@freebsd.org.ru
-
-
-
- Pace Willisson pace@blitz.com
-
-
-
- Paco Rosich rosich@modico.eleinf.uv.es
-
-
-
- Palle Girgensohn girgen@partitur.se
-
-
-
- Parag Patel parag@cgt.com
-
-
-
- Pascal Pederiva pascal@zuo.dec.com
-
-
-
- Pasvorn Boonmark boonmark@juniper.net
-
-
-
- Patrick Gardella patrick@cre8tivegroup.com
-
-
-
- Patrick Hausen unknown
-
-
-
- Paul Antonov apg@demos.su
-
-
-
- Paul F. Werkowski unknown
-
-
-
- Paul Fox pgf@foxharp.boston.ma.us
-
-
-
- Paul Koch koch@thehub.com.au
-
-
-
- Paul Kranenburg pk@NetBSD.org
-
-
-
- Paul Mackerras paulus@cs.anu.edu.au
-
-
-
- Paul Popelka paulp@uts.amdahl.com
-
-
-
- Paul S. LaFollette, Jr. unknown
-
-
-
- Paul Saab paul@mu.org
-
-
-
- Paul Sandys myj@nyct.net
-
-
-
- Paul T. Root proot@horton.iaces.com
-
-
-
- Paul Vixie paul@vix.com
-
-
-
- Paulo Menezes paulo@isr.uc.pt
-
-
-
- Paulo Menezes pm@dee.uc.pt
-
-
-
- Pedro A M Vazquez vazquez@IQM.Unicamp.BR
-
-
-
- Pedro Giffuni giffunip@asme.org
-
-
-
- Pete Bentley pete@demon.net
-
-
-
- Peter Childs pjchilds@imforei.apana.org.au
-
-
-
- Peter Cornelius pc@inr.fzk.de
-
-
-
- Peter Haight peterh@prognet.com
-
-
-
- Peter Jeremy perer.jeremy@alcatel.com.au
-
-
-
- Peter M. Chen pmchen@eecs.umich.edu
-
-
-
- Peter Much peter@citylink.dinoex.sub.org
-
-
-
- Peter Olsson unknown
-
-
-
- Peter Philipp pjp@bsd-daemon.net
-
-
-
- Peter Stubbs PETERS@staidan.qld.edu.au
-
-
-
- Phil Maker pjm@cs.ntu.edu.au
-
-
-
- Phil Sutherland
- philsuth@mycroft.dialix.oz.au
-
-
-
- Phil Taylor phil@zipmail.co.uk
-
-
-
- Philip Musumeci philip@rmit.edu.au
-
-
-
- Pierre Y. Dampure pierre.dampure@k2c.co.uk
-
-
-
- Pius Fischer pius@ienet.com
-
-
-
- Pomegranate daver@flag.blackened.net
-
-
-
- Powerdog Industries
- kevin.ruddy@powerdog.com
-
-
-
- R. Kym Horsell
-
-
-
- Rajesh Vaidheeswarran rv@fore.com
-
-
-
- Ralf Friedl friedl@informatik.uni-kl.de
-
-
-
- Randal S. Masutani randal@comtest.com
-
-
-
- Randall Hopper rhh@ct.picker.com
-
-
-
- Randall W. Dean rwd@osf.org
-
-
-
- Randy Bush rbush@bainbridge.verio.net
-
-
-
- Reinier Bezuidenhout
- rbezuide@mikom.csir.co.za
-
-
-
- Remy Card Remy.Card@masi.ibp.fr
-
-
-
- Ricardas Cepas rch@richard.eu.org
-
-
-
- Richard Henderson richard@atheist.tamu.edu
-
-
-
- Richard Hwang rhwang@bigpanda.com
-
-
-
- Richard J Kuhns rjk@watson.grauel.com
-
-
-
- Richard M. Neswold
- rneswold@drmemory.fnal.gov
-
-
-
- Richard Seaman, Jr. dick@tar.com
-
-
-
- Richard Stallman rms@gnu.ai.mit.edu
-
-
-
- Richard Straka straka@user1.inficad.com
-
-
-
- Richard Tobin richard@cogsci.ed.ac.uk
-
-
-
- Richard Wackerbarth rkw@Dataplex.NET
-
-
-
- Richard Winkel rich@math.missouri.edu
-
-
-
- Richard Wiwatowski rjwiwat@adelaide.on.net
-
-
-
- Rick Macklem rick@snowhite.cis.uoguelph.ca
-
-
-
- Rick Macklin unknown
-
-
-
- Rob Austein sra@epilogue.com
-
-
-
- Rob Mallory rmallory@qualcomm.com
-
-
-
- Rob Snow rsnow@txdirect.net
-
-
-
- Robert Crowe bob@speakez.com
-
-
-
- Robert D. Thrush rd@phoenix.aii.com
-
-
-
- Robert Eckardt
- roberte@MEP.Ruhr-Uni-Bochum.de
-
-
-
- Robert Sanders rsanders@mindspring.com
-
-
-
- Robert Sexton robert@kudra.com
-
-
-
- Robert Shady rls@id.net
-
-
-
- Robert Swindells swindellsr@genrad.co.uk
-
-
-
- Robert Watson robert@cyrus.watson.org
-
-
-
- Robert Withrow witr@rwwa.com
-
-
-
- Robert Yoder unknown
-
-
-
- Robin Carey
- robin@mailgate.dtc.rankxerox.co.uk
-
-
-
- Roger Hardiman roger@cs.strath.ac.uk
-
-
-
- Roland Jesse jesse@cs.uni-magdeburg.de
-
-
-
- Ron Bickers rbickers@intercenter.net
-
-
-
- Ron Lenk rlenk@widget.xmission.com
-
-
-
- Ronald Kuehn kuehn@rz.tu-clausthal.de
-
-
-
- Rudolf Cejka unknown
-
-
-
- Ruslan Belkin rus@home2.UA.net
-
-
-
- Ruslan Ermilov ru@ucb.crimea.ua
-
-
-
- Ruslan Shevchenko rssh@cam.grad.kiev.ua
-
-
-
- Russell L. Carter rcarter@pinyon.org
-
-
-
- Russell Vincent rv@groa.uct.ac.za
-
-
-
- Ryan Younce ryany@pobox.com
-
-
-
- SANETO Takanori sanewo@strg.sony.co.jp
-
-
-
- SAWADA Mizuki miz@qb3.so-net.ne.jp
-
-
-
- SUGIMURA Takashi sugimura@jp.FreeBSD.ORG
-
-
-
- SURANYI Peter
- suranyip@jks.is.tsukuba.ac.jp
-
-
-
- Sakari Jalovaara sja@tekla.fi
-
-
-
- Sam Hartman hartmans@mit.edu
-
-
-
- Samuel Lam skl@ScalableNetwork.com
-
-
-
- Sander Vesik sander@haldjas.folklore.ee
-
-
-
- Sandro Sigala ssigala@globalnet.it
-
-
-
- Sascha Blank blank@fox.uni-trier.de
-
-
-
- Sascha Wildner swildner@channelz.GUN.de
-
-
-
- Satoh Junichi junichi@astec.co.jp
-
-
-
- Satoshi Taoka
- taoka@infonets.hiroshima-u.ac.jp
-
-
-
- Scot Elliott scot@poptart.org
-
-
-
- Scot W. Hetzel hetzels@westbend.net
-
-
-
- Scott A. Kenney saken@rmta.ml.org
-
-
-
- Scott Blachowicz
- scott.blachowicz@seaslug.org
-
-
-
- Scott Burris scott@pita.cns.ucla.edu
-
-
-
- Scott Hazen Mueller scott@zorch.sf-bay.org
-
-
-
- Scott Michel scottm@cs.ucla.edu
-
-
-
- Scott Reynolds scott@clmqt.marquette.mi.us
-
-
-
- Sebastian Strollo seb@erix.ericsson.se
-
-
-
- Seigou TANIMURA
- tanimura@naklab.dnj.ynu.ac.jp
-
-
-
- Serge A. Babkin babkin@hq.icb.chel.su
-
-
-
- Serge V. Vakulenko vak@zebub.msk.su
-
-
-
- Sergei Chechetkin
- csl@whale.sunbay.crimea.ua
-
-
-
- Sergei S. Laskavy laskavy@pc759.cs.msu.su
-
-
-
- Sergey Gershtein sg@mplik.ru
-
-
-
- Sergey Potapov sp@alkor.ru
-
-
-
- Sergey Shkonda serg@bcs.zp.ua
-
-
-
- Sergey V.Dorokhov svd@kbtelecom.nalnet.ru
-
-
-
- Sergio Lenzi lenzi@bsi.com.br
-
-
-
- Shaun Courtney shaun@emma.eng.uct.ac.za
-
-
-
- Shawn M. Carey smcarey@mailbox.syr.edu
-
-
-
- Sheldon Hearn axl@iafrica.com
-
-
-
- Shigio Yamaguchi shigio@wafu.netgate.net
-
-
-
- Shunsuke Akiyama akiyama@jp.freebsd.org
-
-
-
- Simon simon@masi.ibp.fr
-
-
-
- Simon Burge simonb@telstra.com.au
-
-
-
- Simon J Gerraty sjg@melb.bull.oz.au
-
-
-
- Simon Marlow simonm@dcs.gla.ac.uk
-
-
-
- Simon Shapiro shimon@simon-shapiro.org
-
-
-
- Sin'ichiro MIYATANI siu@phaseone.co.jp
-
-
-
- Slaven Rezic eserte@cs.tu-berlin.de
-
-
-
- Soochon Radee slr@mitre.org
-
-
-
- Soren Dayton csdayton@midway.uchicago.edu
-
-
-
- Soren Dossing sauber@netcom.com
-
-
-
- Soren S. Jorvang soren@dt.dk
-
-
-
- Stefan Bethke stb@hanse.de
-
-
-
- Stefan Eggers seggers@semyam.dinoco.de
-
-
-
- Stefan Moeding s.moeding@ndh.net
-
-
-
- Stefan Petri unknown
-
-
-
- Stefan `Sec` Zehl sec@42.org
-
-
-
- Steinar Haug sthaug@nethelp.no
-
-
-
- Stephane E. Potvin sepotvin@videotron.ca
-
-
-
- Stephane Legrand stephane@lituus.fr
-
-
-
- Stephen Clawson
- sclawson@marker.cs.utah.edu
-
-
-
- Stephen F. Combs combssf@salem.ge.com
-
-
-
- Stephen Farrell stephen@farrell.org
-
-
-
- Stephen Hocking sysseh@devetir.qld.gov.au
-
-
-
- Stephen J. Roznowski sjr@home.net
-
-
-
- Stephen McKay syssgm@devetir.qld.gov.au
-
-
-
- Stephen Melvin melvin@zytek.com
-
-
-
- Steve Bauer sbauer@rock.sdsmt.edu
-
-
-
- Steve Deering unknown
-
-
-
- Steve Gerakines steve2@genesis.tiac.net
-
-
-
- Steve Gericke steveg@comtrol.com
-
-
-
- Steve Piette steve@simon.chi.il.US
-
-
-
- Steve Schwarz schwarz@alpharel.com
-
-
-
- Steven G. Kargl
- kargl@troutmask.apl.washington.edu
-
-
-
- Steven H. Samorodin samorodi@NUXI.com
-
-
-
- Steven McCanne mccanne@cs.berkeley.edu
-
-
-
- Steven Plite splite@purdue.edu
-
-
-
- Steven Wallace unknown
-
-
-
- Stuart Henderson
- stuart@internationalschool.co.uk
-
-
-
- Sue Blake sue@welearn.com.au
-
-
-
- Sugiura Shiro ssugiura@duo.co.jp
-
-
-
- Sujal Patel smpatel@wam.umd.edu
-
-
-
- Sune Stjerneby stjerneby@usa.net
-
-
-
- Suzuki Yoshiaki
- zensyo@ann.tama.kawasaki.jp
-
-
-
- Tadashi Kumano kumano@strl.nhk.or.jp
-
-
-
- Taguchi Takeshi taguchi@tohoku.iij.ad.jp
-
-
-
- Takahashi Yoshihiro nyan@dd.catv.ne.jp
-
-
-
- Takahiro Yugawa yugawa@orleans.rim.or.jp
-
-
-
- Takanori Watanabe
- takawata@shidahara1.planet.sci.kobe-u.ac.jp
-
-
-
- Takashi Mega mega@minz.org
-
-
-
- Takashi Uozu j1594016@ed.kagu.sut.ac.jp
-
-
-
- Takayuki Ariga a00821@cc.hc.keio.ac.jp
-
-
-
- Takeru NAIKI naiki@bfd.es.hokudai.ac.jp
-
-
-
- Takeshi Amaike amaike@iri.co.jp
-
-
-
- Takeshi MUTOH mutoh@info.nara-k.ac.jp
-
-
-
- Takeshi Ohashi
- ohashi@mickey.ai.kyutech.ac.jp
-
-
-
- Takeshi WATANABE
- watanabe@crayon.earth.s.kobe-u.ac.jp
-
-
-
- Takuya SHIOZAKI
- tshiozak@makino.ise.chuo-u.ac.jp
-
-
-
- Tatoku Ogaito tacha@tera.fukui-med.ac.jp
-
-
-
- Tatsumi HOSOKAWA hosokawa@jp.FreeBSD.org
-
-
-
- Ted Buswell tbuswell@mediaone.net
-
-
-
- Ted Faber faber@isi.edu
-
-
-
- Ted Lemon unknown
-
-
-
- Terry Lambert terry@lambert.org
-
-
-
- Terry Lee terry@uivlsi.csl.uiuc.edu
-
-
-
- Tetsuya Furukawa tetsuya@secom-sis.co.jp
-
-
-
- Theo de Raadt deraadt@OpenBSD.org
-
-
-
- Thomas thomas@mathematik.uni-Bremen.de
-
-
-
- Thomas D. Dean tomdean@ix.netcom.com
-
-
-
- Thomas David Rivers rivers@dignus.com
-
-
-
- Thomas G. McWilliams tgm@netcom.com
-
-
-
- Thomas Gellekum
- thomas@ghpc8.ihf.rwth-aachen.de
-
-
-
- Thomas Graichen
- graichen@omega.physik.fu-berlin.de
-
-
-
- Thomas König
- Thomas.Koenig@ciw.uni-karlsruhe.de
-
-
-
- Thomas Ptacek unknown
-
-
-
- Thomas Stromberg tstrombe@rtci.com
-
-
-
- Thomas Valentino Crimi
- tcrimi+@andrew.cmu.edu
-
-
-
- Thomas Wintergerst thomas@lemur.nord.de
-
-
-
- Þórður Ívarsson
- totii@est.is
-
-
-
- Tim Kientzle kientzle@netcom.com
-
-
-
- Tim Singletary
- tsingle@sunland.gsfc.nasa.gov
-
-
-
- Tim Wilkinson tim@sarc.city.ac.uk
-
-
-
- Timo J. Rinne tri@iki.fi
-
-
-
- Todd Miller millert@openbsd.org
-
-
-
- Tom root@majestix.cmr.no
-
-
-
- Tom tom@sdf.com
-
-
-
- Tom Gray - DCA dcasba@rain.org
-
-
-
- Tom Hukins tom@eborcom.com
-
-
-
- Tom Jobbins tom@tom.tj
-
-
-
- Tom Pusateri pusateri@juniper.net
-
-
-
- Tom Rush tarush@mindspring.com
-
-
-
- Tom Samplonius tom@misery.sdf.com
-
-
-
- Tomohiko Kurahashi
- kura@melchior.q.t.u-tokyo.ac.jp
-
-
-
- Tony Kimball alk@Think.COM
-
-
-
- Tony Li tli@jnx.com
-
-
-
- Tony Lynn wing@cc.nsysu.edu.tw
-
-
-
- Torbjorn Granlund tege@matematik.su.se
-
-
-
- Toshihiko ARAI toshi@tenchi.ne.jp
-
-
-
- Toshihiko SHIMOKAWA toshi@tea.forus.or.jp
-
-
-
- Toshihiro Kanda candy@kgc.co.jp
-
-
-
- Toshiomi Moriki
- Toshiomi.Moriki@ma1.seikyou.ne.jp
-
-
-
- Trefor S. trefor@flevel.co.uk
-
-
-
- Trevor Blackwell tlb@viaweb.com
-
-
-
- URATA Shuichiro s-urata@nmit.tmg.nec.co.jp
-
-
-
- Ugo Paternostro paterno@dsi.unifi.it
-
-
-
- Ulf Kieber kieber@sax.de
-
-
-
- Ulli Linzen ulli@perceval.camelot.de
-
-
-
- Ustimenko Semen semen@iclub.nsu.ru
-
-
-
- Uwe Arndt arndt@mailhost.uni-koblenz.de
-
-
-
- Vadim Chekan vadim@gc.lviv.ua
-
-
-
- Vadim Kolontsov vadim@tversu.ac.ru
-
-
-
- Vadim Mikhailov mvp@braz.ru
-
-
-
- Van Jacobson van@ee.lbl.gov
-
-
-
- Vasily V. Grechishnikov
- bazilio@ns1.ied-vorstu.ac.ru
-
-
-
- Vasim Valejev vasim@uddias.diaspro.com
-
-
-
- Vernon J. Schryver vjs@mica.denver.sgi.com
-
-
-
- Vic Abell abe@cc.purdue.edu
-
-
-
- Ville Eerola ve@sci.fi
-
-
-
- Vincent Poy vince@venus.gaianet.net
-
-
-
- Vincenzo Capuano
- VCAPUANO@vmprofs.esoc.esa.de
-
-
-
- Virgil Champlin champlin@pa.dec.com
-
-
-
- Vladimir A. Jakovenko
- vovik@ntu-kpi.kiev.ua
-
-
-
- Vladimir Kushnir kushn@mail.kar.net
-
-
-
- Vsevolod Lobko seva@alex-ua.com
-
-
-
- W. Gerald Hicks wghicks@bellsouth.net
-
-
-
- W. Richard Stevens rstevens@noao.edu
-
-
-
- Walt Howard howard@ee.utah.edu
-
-
-
- Warren Toomey wkt@csadfa.cs.adfa.oz.au
-
-
-
- Wayne Scott wscott@ichips.intel.com
-
-
-
- Werner Griessl
- werner@btp1da.phy.uni-bayreuth.de
-
-
-
- Wes Santee wsantee@wsantee.oz.net
-
-
-
- Wietse Venema wietse@wzv.win.tue.nl
-
-
-
- Wilfredo Sanchez wsanchez@apple.com
-
-
-
- Wiljo Heinen wiljo@freeside.ki.open.de
-
-
-
- Wilko Bulte wilko@yedi.iaf.nl
-
-
-
- Willem Jan Withagen wjw@surf.IAE.nl
-
-
-
- William Jolitz withheld
-
-
-
- William Liao william@tale.net
-
-
-
- Wojtek Pilorz
- wpilorz@celebris.bdk.lublin.pl
-
-
-
- Wolfgang Helbig helbig@ba-stuttgart.de
-
-
-
- Wolfgang Solfrank ws@tools.de
-
-
-
- Wolfgang Stanglmeier wolf@FreeBSD.org
-
-
-
- Wu Ching-hong woju@FreeBSD.ee.Ntu.edu.TW
-
-
-
- Yarema yds@ingress.com
-
-
-
- Yaroslav Terletsky ts@polynet.lviv.ua
-
-
-
- Yen-Shuo Su yssu@CCCA.NCTU.edu.tw
-
-
-
- Ying-Chieh Liao ijliao@csie.NCTU.edu.tw
-
-
-
- Yixin Jin yjin@rain.cs.ucla.edu
-
-
-
- Yoshiaki Uchikawa yoshiaki@kt.rim.or.jp
-
-
-
- Yoshihiko OHTA yohta@bres.tsukuba.ac.jp
-
-
-
- Yoshihisa NAKAGAWA
- y-nakaga@ccs.mt.nec.co.jp
-
-
-
- Yoshikazu Goto gotoh@ae.anritsu.co.jp
-
-
-
- Yoshimasa Ohnishi
- ohnishi@isc.kyutech.ac.jp
-
-
-
- Yoshishige Arai ryo2@on.rim.or.jp
-
-
-
- Yuichi MATSUTAKA matutaka@osa.att.ne.jp
-
-
-
- Yujiro MIYATA
- miyata@bioele.nuee.nagoya-u.ac.jp
-
-
-
- Yukihiro Nakai nacai@iname.com
-
-
-
- Yusuke Nawano azuki@azkey.org
-
-
-
- Yuval Yarom yval@cs.huji.ac.il
-
-
-
- Yves Fonk yves@cpcoup5.tn.tudelft.nl
-
-
-
- Yves Fonk yves@dutncp8.tn.tudelft.nl
-
-
-
- Zach Heilig zach@gaffaneys.com
-
-
-
- Zahemszhky Gabor zgabor@code.hu
-
-
-
- Zhong Ming-Xun zmx@mail.CDPA.nsysu.edu.tw
-
-
-
- arci vega@sophia.inria.fr
-
-
-
- der Mouse mouse@Collatz.McRCIM.McGill.EDU
-
-
-
- frf frf@xocolatl.com
-
-
-
- Ege Rekk aagero@aage.priv.no
-
-
-
-
-
- Collaborateurs pour les correctif 386BSD
-
- (En ordre alphabétique par prénom) :
-
-
-
- Adam Glass glass@postgres.berkeley.edu
-
-
-
- Adrian Hall adrian@ibmpcug.co.uk
-
-
-
- Andrey A. Chernov ache@astral.msk.su
-
-
-
- Andrew Herbert andrew@werple.apana.org.au
-
-
-
- Andrew Moore alm@netcom.com
-
-
-
- Andy Valencia ajv@csd.mot.com
- jtk@netcom.com
-
-
-
- Arne Henrik Juul arnej@Lise.Unit.NO
-
-
-
- Bakul Shah bvs@bitblocks.com
-
-
-
- Barry Lustig barry@ictv.com
-
-
-
- Bob Wilcox bob@obiwan.uucp
-
-
-
- Branko Lankester
-
-
-
- Brett Lymn blymn@mulga.awadi.com.AU
-
-
-
- Charles Hannum mycroft@ai.mit.edu
-
-
-
- Chris G. Demetriou
- cgd@postgres.berkeley.edu
-
-
-
- Chris Torek torek@ee.lbl.gov
-
-
-
- Christoph Robitschko
- chmr@edvz.tu-graz.ac.at
-
-
-
- Daniel Poirot poirot@aio.jsc.nasa.gov
-
-
-
- Dave Burgess burgess@hrd769.brooks.af.mil
-
-
-
- Dave Rivers rivers@ponds.uucp
-
-
-
- David Dawes dawes@physics.su.OZ.AU
-
-
-
- David Greenman dg@Root.COM
-
-
-
- Eric J. Haug ejh@slustl.slu.edu
-
-
-
- Felix Gaehtgens
- felix@escape.vsse.in-berlin.de
-
-
-
- Frank Maclachlan fpm@crash.cts.com
-
-
-
- Gary A. Browning gab10@griffcd.amdahl.com
-
-
-
- Gary Howland gary@hotlava.com
-
-
-
- Geoff Rehmet csgr@alpha.ru.ac.za
-
-
-
- Goran Hammarback goran@astro.uu.se
-
-
-
- Guido van Rooij guido@gvr.org
-
-
-
- Guy Harris guy@auspex.com
-
-
-
- Havard Eidnes
- Havard.Eidnes@runit.sintef.no
-
-
-
- Herb Peyerl hpeyerl@novatel.cuc.ab.ca
-
-
-
- Holger Veit Holger.Veit@gmd.de
-
-
-
- Ishii Masahiro, R. Kym Horsell
-
-
-
- J.T. Conklin jtc@cygnus.com
-
-
-
- Jagane D Sundar jagane@netcom.com
-
-
-
- James Clark jjc@jclark.com
-
-
-
- James Jegers jimj@miller.cs.uwm.edu
-
-
-
- James W. Dolter
-
-
-
- James da Silva jds@cs.umd.edu et al
-
-
-
- Jay Fenlason hack@datacube.com
-
-
-
- Jim Wilson wilson@moria.cygnus.com
-
-
-
- Jörg Lohse
- lohse@tech7.informatik.uni-hamburg.de
-
-
-
- Jörg Wunsch
- joerg_wunsch@uriah.heep.sax.de
-
-
-
- John Dyson
-
-
-
- John Woods jfw@eddie.mit.edu
-
-
-
- Jordan K. Hubbard jkh@whisker.hubbard.ie
-
-
-
- Julian Elischer julian@dialix.oz.au
-
-
-
- Julian Stacey jhs@freebsd.org
-
-
-
- Karl Dietz Karl.Dietz@triplan.com
-
-
-
- Karl Lehenbauer karl@NeoSoft.com
- karl@one.neosoft.com
-
-
-
- Keith Bostic bostic@toe.CS.Berkeley.EDU
-
-
-
- Ken Hughes
-
-
-
- Kent Talarico kent@shipwreck.tsoft.net
-
-
-
- Kevin Lahey kml%rokkaku.UUCP@mathcs.emory.edu
- kml@mosquito.cis.ufl.edu
-
-
-
- Marc Frajola marc@dev.com
-
-
-
- Mark Tinguely tinguely@plains.nodak.edu
- tinguely@hookie.cs.ndsu.NoDak.edu
-
-
-
- Martin Renters martin@tdc.on.ca
-
-
-
- Michael Clay mclay@weareb.org
-
-
-
- Michael Galassi nerd@percival.rain.com
-
-
-
- Mike Durkin mdurkin@tsoft.sf-bay.org
-
-
-
- Naoki Hamada nao@tom-yam.or.jp
-
-
-
- Nate Williams nate@bsd.coe.montana.edu
-
-
-
- Nick Handel nhandel@NeoSoft.com
- nick@madhouse.neosoft.com
-
-
-
- Pace Willisson pace@blitz.com
-
-
-
- Paul Kranenburg pk@cs.few.eur.nl
-
-
-
- Paul Mackerras paulus@cs.anu.edu.au
-
-
-
- Paul Popelka paulp@uts.amdahl.com
-
-
-
- Peter da Silva peter@NeoSoft.com
-
-
-
- Phil Sutherland
- philsuth@mycroft.dialix.oz.au
-
-
-
- Poul-Henning Kampphk@FreeBSD.ORG
-
-
-
- Ralf Friedl friedl@informatik.uni-kl.de
-
-
-
- Rick Macklem root@snowhite.cis.uoguelph.ca
-
-
-
- Robert D. Thrush rd@phoenix.aii.com
-
-
-
- Rodney W. Grimes rgrimes@cdrom.com
-
-
-
- Sascha Wildner swildner@channelz.GUN.de
-
-
-
- Scott Burris scott@pita.cns.ucla.edu
-
-
-
- Scott Reynolds scott@clmqt.marquette.mi.us
-
-
-
- Sean Eric Fagan sef@kithrup.com
-
-
-
- Simon J Gerraty sjg@melb.bull.oz.au
- sjg@zen.void.oz.au
-
-
-
- Stephen McKay syssgm@devetir.qld.gov.au
-
-
-
- Terry Lambert terry@icarus.weber.edu
-
-
-
- Terry Lee terry@uivlsi.csl.uiuc.edu
-
-
-
- Tor Egge Tor.Egge@idi.ntnu.no
-
-
-
- Warren Toomey wkt@csadfa.cs.adfa.oz.au
-
-
-
- Wiljo Heinen wiljo@freeside.ki.open.de
-
-
-
- William Jolitz withheld
-
-
-
- Wolfgang Solfrank ws@tools.de
-
-
-
- Wolfgang Stanglmeier wolf@dentaro.GUN.de
-
-
-
- Yuval Yarom yval@cs.huji.ac.il
-
-
-
-
-
-
-
-
diff --git a/fr_FR.ISO8859-1/books/handbook/hw/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/hw/chapter.sgml
deleted file mode 100644
index 8d226e1099..0000000000
--- a/fr_FR.ISO8859-1/books/handbook/hw/chapter.sgml
+++ /dev/null
@@ -1,5780 +0,0 @@
-
-
-
- ** Compatibilité matérielle
- &trans.a.haby;
-
-
- Les questions de compatibilité matérielle sont aujourd'hui
- les plus problématiques de l'industrie informatique et FreeBSD
- n'en est nullement à l'abri. De ce point de vue, l'avantage qu'a
- FreeBSD de pouvoir être utilisé sur du matériel PC courant et
- peu coûteux est aussi une difficulté lorsqu'il faut supporter
- l'incroyable variété de composants disponibles.
- Il est impossible de donner une liste exhaustive des matériels
- compatibles avec FreeBSD, mais ce chapitre est un catalogue des
- pilotes de périphériques inclus dans FreeBSD et des matériels que
- chaque pilote supporte. Si possible et approprié, des notes ont
- ajoutées sur les matériels eux-mêmes. Vous pouvez aussi vous
- référer au chapitre Configurer
- le noyau de FreeBSD de ce manuel pour avoir
- la liste des matériels supportés.
-
- FreeBSD est un projet bénévole qui n'a pas les moyens de financer
- un service de tests, nous reposons sur vous, les utilisateurs, pour une
- grande part des informations que fournit ce catalogue. Si vous avez
- l'expérience personnelle d'un matériel qui fonctionne ou ne fonctionne
- pas avec FreeBSD, faites-le nous savoir par courrier électronique
- à &a.doc;. Les questions concernant les matériels compatibles doivent
- être adressées à &a.questions; (voyez la section
- Listes de diffusion
- pour plus d'informations). Quand vous nous faites
- parvenir de l'information ou posez une question, n'oubliez pas s'il vous
- plaît de préciser exactement quelle version de FreeBSD vous utilisez et
- de donner le maximum de détails sur votre configuration
- matérielle.
-
-
- Ressources Internet
-
- Les liens donnés ci-dessous se sont avérés utiles pour guider
- dans les choix de matériels. Bien que les renseignements qu'ils vous
- donnent ne soient pas nécessairement spécifiques (ou même
- applicables) à FreeBSD, ils ne dépendent pas, pour la plupart
- du système d'exploitation. Vérifiez s'il vous plaît dans le guide
- du matériel pour FreeBSD que la configuration que vous avez choisie
- soit compatible avec FreeBSD avant d'acheter quoi que ce soit.
-
-
-
-
-
- The Pentium
- Systems Hardware Performance Guide - le
- guide des performances des systèmes Pentium.
-
-
-
-
-
-
-
-
- Exemples de configurations
-
- La liste de configurations ci-dessous ne constitue en aucun
- cas une publicité pour un constructeur ou un produit de la
- part du Projet FreeBSD. Ces informations ne
- sont données que pour être utiles et rassemblent simplement les
- expériences de différentes personnes sur des configurations variées.
- Tarifs indicatifs. Chaussée glissante. Attention au chien.
-
-
- La sélection de Jordan
-
- J'ai obtenu de bons résultats en mettant sur pied des stations
- de travail et des serveurs avec les composants ci-dessous. Je ne
- peut vous garantir que vous en aurez aussi, ni qu'aucune des marques
- citées restera “le meilleur choix”. J'essaierai, si
- possible, de tenir cette liste à jour, mais ne peux bien évidemment
- vous assurer qu'elle le soit à un moment donné.
-
-
- Cartes mères
-
- Pour les systèmes Pentium Pro (P6), j'aime assez la carte mère
- bi-processseurs
- Tyan
- S1668. Elle fait un sympathique système à un ou deux processeurs
- (ce que supporte FreeBSD 3.0) et le prix du Pentium Pro 180/256K
- a maintenant baissé à un niveau vraiment abordable. Le Pentium Pro
- reste mon processeur favori pour les serveurs (les mégahertzs ne
- font pas tout).
-
- Pour les Pentium II, j'ai un sérieux préjugé en faveur de la
- carte mère ASUS
- P2l97-S
- avec contrôleur WIDE SCSI intégré.
-
- Pour les machines Pentium, la carte mère ASUS
- P55T2P4
- paraît un bon choix pour un serveur ou une station de travail
- de taille moyenne à importante. Vous pouvez aussi
- regarder du côté de la carte
- 486SP3G,
- si vous cherchez une carte mère 486.
-
-
- (Il semble qu'il soit devenu difficile de se procurer ces
- dernières, qu'ASUS ne fabrique apparemment plus.)
-
-
- Ceux qui veulent utiliser des systèmes plus tolérants aux
- erreurs doivent veiller à employer de la mémoire avec contrôle
- de parité, ou ECC, pour des applications non-stop.
-
-
- La mémoire ECC entraîne une petite perte de performances
- (que vous remarquerez ou non selon votre application) mais vous
- apporte des gains significatifs en termes de tolérance
- d'erreur.
-
-
-
-
- Contrôleurs de disque
-
- C'est un point plus délicat. J'utilisais
- inconditionnellement des contrôleurs
- Buslogic
- pour tout, de l'ISA au PCI, j'incline maintenant plutôt vers
- le contrôleur Adaptec 1542CF pour l'ISA,
- le contrôleur Buslogic Bt747c pour l'EISA et le contrôleur
- Adaptec 2940UW pour le PCI.
-
- J'ai aussi eu de bons résultats avec les cartes
- PCI NCR/Symbios, bien qu'il faille s'assurer que
- votre carte mère supporte le modèle sans BIOS (s'il n'y
- a rien sur votre carte qui ressemble vaguement à une puce
- ROM, c'est probablement un modèle qui s'attend à ce que son
- BIOS soit sur la carte mère).
-
- Si vous pensez qu'il vous faut plus d'un contrôleur SCSI,
- vous pouvez songer à économiser vos maigres ressources en
- emplacements PCI en achetant une carte Adaptec 3940, qui
- intègre deux contrôleurs PCI sur un seul connecteur.
-
-
-
-
- Disques durs
-
- Pour cette version particulière de la roulette russe, je
- donnerais peu de conseils précis sinon pour recommander
- “du SCSI plutôt que de l'IDE dès que vous pouvez vous
- l'offrir”. Même sur de petites machines de bureau, le SCSI
- est souvent un meilleur choix parce qu'il vous permet de
- migrer vos disques du serveur vers la machine de bureau lorsque
- les prix en chute des disques en font une solution économiquement
- viable. Si vous avez plus d'une machine à administrer, ne pensez
- pas seulement en terme de stockage, voyez plutôt cela comme
- une chaîne alimentaire!
-
- Je ne trouve pas que les disques WIDE SCSI représentent
- un investissement nécessaire, à moins que vous ne mettiez en place
- un serveur NFS ou des forums de discussion
- qui devront supporter beaucoup d'accès disque pour de nombreux
- utilisateurs.
-
-
-
-
- Lecteur de CD-ROMs
-
- Ma préférence pour le SCSI s'applique aussi aux lecteurs de
- CD-ROMs SCSI, et bien que j'ai toujours eu de bons résultats
- avec le modèle Toshiba
- XM-3501B (qui existe aussi en version tiroir sous la référence
- XM-5401B), je suis maintenant très partisan du lecteur
- Plextor PX-12CS.
- C'est un lecteur 12x dont les performances et la fiabilité sont
- excellentes.
-
- D'une façon générale, la plupart des lecteurs de CD-ROMs SCSI
- que j'ai vus, sont de fabrication robuste et vous ne vous
- tromperez pas non plus si vous prenez un modèle HP ou NEC. Le prix
- des lecteurs de CD-ROMs SCSI semble avoir aussi considérablement
- baissé ces derniers mois et devient compétitif avec celui des
- lecteurs IDE, alors qu'ils restent techniquement supérieurs. A
- choisir entre les deux, je ne vois pas de raison de se décider
- pour un lecteur IDE.
-
-
-
-
- Graveurs de CD-ROMs non réinscriptibles
-
- Au moment où j'écris ceci, FreeBSD supporte trois types de
- graveurs de CD-ROMs (bien que je pense qu'ils viennent en fait
- tous de chez Phillips): le Phillips CDD 522 (se comporte comme
- le Plasmon), le Plasmon RF4100 et le HP 6020i. J'utilise
- personnellement le HP 6020i pour graver mes CD-ROMs (avec la
- version 2.2-current de FreeBSD - il ne fonctionne pas
- avec la version 2.1.5 et les versions antérieures du pilote SCSI)
- qui me donne toute satisfaction. Regardez dans le fichier
- /usr/share/examples/worm
- sur votre système 2.2 pour avoir des exemples de procédures pour
- créer des images au format ISO9660 (avec les extensions RockRidge)
- de vos systèmes de fichiers et graver ensuite des CD-ROMs avec un
- HP6020i.
-
-
-
-
- Lecteurs de bandes
-
- J'ai obtenu de bons résultats avec les lecteurs
- 8mm
- de chez
- Exabyte
- et
- 4mm (DAT)
- de chez HP.
-
- Pour les sauvegardes, je recommande les Exabytes pour la
- robustesse (et la plus grande capacité) des bandes 8mm.
-
-
-
-
- Cartes graphiques
-
- Si vous pouvez aussi vous offrir un serveur X commercial
- pour 99$ US de chez
- Xi Graphics, Inc. (autrefois, X Inside, Inc)
- alors je vous recommande vivement la carte
- Matrox
- Millenium.
- Cette carte est aussi très bien supportée par le serveur
- XFree86,
- qui en est maintenant à sa version 3.3.2.
-
- Les cartes
- Number 9 sont aussi
- un excellent choix - leurs cartes Vision 868 et 968
- (la série 9FX) basées sur le circuit S3 sont aussi très rapides
- et bien gérées par le pilote S3 du serveur XFree86.
-
-
-
-
- Moniteurs
-
- J'ai eu d'excellents résultats avec les moniteurs
- Sony Multiscan 17seII,
- et avec le Viewsonic qui utilise le même tube (Trinitron). Pour
- des modèles au-delà de 17", tout ce que je peux aujourd'hui
- conseiller est de ne pas dépenser moins de 2.500 $ pour
- un moniteur 21" ou 1.700 $ pour un 20", si vous en avez
- vraiment besoin. Il y de bons écrans dans
- la gamme des 20" et plus,
- et il y en a aussi de bon marché. Malheureusement, il y en a très
- peu qui soient à la fois de bonne qualité et bon marché!
-
-
-
-
- Réseau
-
- Je peux recommander le contrôleur SMC Ultra 16 pour les
- applications ISA et les cartes SMC EtherPower ou Compex ENET32
- pour les réseaux importants basés sur du PCI. Ces deux cartes
- PCI sont construites autour de la puce contrôleur Ethernet
- DEC DC21041 et les autres cartes qui employent cette puce, telles
- que la Zynx ZX432 et la DEC DE435, fonctionneront aussi. Pour
- les réseaux 100Mbit, les cartes SMC SMC9332DST 10/100MB ou Intel
- Intel EtherExpress Pro/100B font du bon travail, ma préférence
- allant à la carte Intel EtherExpress.
-
- Si d'un autre côté vous cherchez la solution la moins chère
- possible, mais qui fonctionne malgré tout raisonnablement, alors
- pratiquement n'importe quel clone NE2000 est un bon choix.
-
-
-
-
- Série
-
- Si vous cherchez des solutions pour un réseau série à grande
- vitesse, alors Digi
- International fabrique la série SYNC/570,
- pour laquelle FreeBSD-current a maintenant des pilotes.
- Emerging Technologies
- fabrique aussi une carte avec des fonctionnalités T1/E1,
- qui utilise du logiciel qu'il fournit.
- Je n'ai cependant pas l'expérience personnelle de ces deux
- produits.
-
- Les possibilités de cartes multi-ports sont quelque peu plus
- nombreuses, bien que le support par FreeBSD des produits
- Cyclades soit
- réputé le plus complet, essentiellement en raison de
- l'engagement pris par cette compagnie de nous fournir du
- matériel pour évaluation et des spécifications techniques. J'ai
- entendu dire que la Cyclom-16Ye offrait le meilleur rapport
- prix/performances, mais je n'ai pas consulté les tarifs récents.
- D'autres cartes multi-ports dont j'ai entendu dire du bien
- sont les BOCA et les AST, et Stallion
- Technologies propose apparemment ici
- un pilote non officiel pour ses cartes.
-
-
-
-
- Audio
-
- J'utilise actuellement une AWE32 de Creative Labs, bien qu'à peu
- près tout ce qui vient de chez Creative Labs marcherait
- aujourd'hui. Ce qui ne veut pas dire que d'autres cartes son
- ne marchent pas, simplemement je n'en ai qu'une expérience
- limitée (j'aimais bien autrefois les cartes GUS, mais la
- situation des cartes Gravis est délicate depuis quelque
- temps).
-
-
-
-
- Vidéo
-
- Pour la capture vidéo, il y a deux bons
- choix - n'importe
- quelle carte à base de puce Brooktree BT848, comme les Hauppauge
- ou les WinTV, marchera à merveille avec FreeBSD. Une autre carte
- que j'utilise est la
- Matrox Meteor.
- FreeBSD supporte aussi la carte d'incrustation vidéo plus ancienne
- de chez Creative Labs, mais elles deviennent difficiles à trouver.
- Notez que la carte Meteor ne fonctionnera pas
- avec les cartes mères qui ont un contrôleur 440FX! Consultez
- la section
- Cartes mères pour plus de
- détails. Dans ce cas, il vaut mieux prendre une carte
- BT848.
-
-
-
-
-
-
- Composants de base/Processeurs
-
-
- Cartes mères, bus et contrôleurs de bus
-
-
- * ISA
-
-
-
-
- * EISA
-
-
-
-
- * VLB
-
-
-
-
- PCI
-
- Contribution de &a.rgrimes;.25 Avril
- 1995.
-
- Mises à jour de &a.jkh;.Dernière mise à jour le 26 Août
- 1996.
-
- Parmi les contrôleurs INTEL PCI, la liste suivante décrit
- différents types de problème connus, et leur gravité, du pire
- au meilleur.
-
-
- Mercury:
-
- Problèmes de cohérence du cache, en particulier s'il
- y a des contrôleurs de bus ISA en plus du pont ISA/PCI.
- C'est un problème matériel, la seule solution consiste
- à désactiver le cache.
-
-
-
- Saturn-I (i.e., 82424ZX en i
- révision 0, 1 ou 2):
-
-
- Problème de cohérence lors de la réécriture dans le
- cache. C'est un problème matériel. La seule parade
- consiste à configurer le cache externe en mode
- transparent. Ou à passer à la version Saturn-II.
-
-
-
- Saturn-II (i.e., 82424ZX en
- révision 3 ou 4):
-
-
- Fonctionne bien, mais de nombreux fabriquants de
- carte mère ne se préoccupent pas du bit SRAM nécessaire
- aux opérations de réecriture. On peut y pallier en
- utilisant le mode transparent ou en gérant le bit SRAM.
- (J'ai fait cela avec une ASUS PCI/I-486SP3G révision 1.6
- et des cartes plus récentes).
-
-
-
- Neptune:
-
-
- Ne peut gérer plus de deux contrôleurs de bus. C'est
- une erreur de conception reconnue par Intel. Parmi les
- solutions: ne pas utiliser plus de deux contrôleurs,
- matériel spécialement conçu pour remplacer l'arbitre de
- bus PCI (apparu avec l'Intel Altair et d'autres cartes
- mères pour serveur Intel), et bien sûr la réponse
- officielle d'Intel, le remplacer par un Triton, nous
- “l'y avons mis”.
-
-
-
- Triton (ie,
- 430FX):
-
-
- Pas de problème de cohérence du cache ou de contrôle
- du bus connu. Mais cette puce n'implémente tout simplement
- pas le contrôle de parité. Contournez le problème de
- parité. Utilisez des cartes Triton-II si vous avez
- le choix.
-
-
-
- Triton-II (ie,
- 430HX):
-
-
- Tous les échos sur les cartes mères avec cette puce
- sont jusqu'ici favorables. Pas de problème connu.
-
-
-
- Orion:
-
-
- Les premières versions de cette puce souffraient d'un
- retard en écriture PCI qui entraînait des dégradations
- sensibles de performance des applications gourmandes en
- trafic sur le bus PCI. Les versions B0 et ultérieures de
- cette puce ont réglé ce problème.
-
-
-
- 440FX:
-
-
- Cette puce pour Pentium Pro
- semble fonctionner correctement et ne souffre pas des
- problèmes qu'ont connus
- les premières puces Orion. Il accepte
- aussi une plus grande variété de types de mémoire, y compris
- l'ECC et le contrôle de parité. Le seul problème connu est
- que la carte d'acquisition vidéo Matrox Meteor ne fonctionne
- pas avec.
-
-
-
-
-
-
-
-
-
- Processeurs/Coprocesseurs
-
- Contribution de &a.asami;.26 Décembre
- 1997.
-
-
- P6 (Pentium Pro/Pentium II)
-
- Le Pentium Pro et le Pentium II fonctionnent parfaitement
- avec FreeBSD.
- De fait, notre site ftp de base ftp.freebsd.org (aussi
- appelé "ftp.cdrom.com", le site ftp le plus
- important au monde) utilise FreeBSD sur un Pentium Pro. Des Détails de la configuration sont disponibles si vous êtes intéressés.
-
-
-
-
- Pentium
-
- Les Pentium Intel (P54C), Pentium MMX (P55C), AMD K6 et
- Cyrix/IBM 6x86MX fonctionnent tous avec FreeBSD. Je n'entrerai
- pas dans le détail de savoir lequel est plus rapide que l'autre,
- il y a des zillions de sites Web sur l'Internet pour vous
- l'expliquer à l'endroit et à l'envers.
- :)
-
-
- Les différents processeurs ont besoin d'une alimentation
- et d'une ventilation différentes. Assurez-vous que votre carte
- mère fournit la tension exacte requise par votre processeur. Par
- exemple, de nombreuses puces MMX ont besoin d'une alimentation
- dédoublée (e.g., 2.9V pour l'unité centrale, 3.3V pour les
- entrées/sorties). Certaines puces AMD et Cyrix/IBM chauffent
- plus que les puces Intel. Dans ce cas, vérifiez que vous avez
- bien les bons radiateurs et ventilateurs (vous pouvez trouver la
- liste des composants certifiés sur leurs pages Web).
-
-
-
- Vitesses d'horloge
-
- Contribution de &a.rgrimes;.1
- Octobre 1996.
-
- Mise à jour de &a.asami;.27 Décembre
- 1997.
-
- Les machines de la catégorie Pentium utilisent des vitesses
- d'horloge différentes pour leurs différents composants. Il y a
- la fréquence du processeur, celle du bus mémoire externe et
- celle du bus PCI. Il n'est pas toujours exact qu'un processeur
- “plus rapide” compose un système plus rapide
- qu'un “plus lent”, du fait de ces différentes
- vitesses d'horloge. Voici une table qui donne la liste des
- possibilités:
-
-
-
-
-
- Fréquence du processeur (MHz)
- Horloge externe et fréquence du bus mémoire (mHz)
- [a]
- Coefficient multiplicateur horloge
- interne/externe
- Fréquence du bus PCI (MHz)
-
-
-
-
- 60
- 60
- 1.0
- 30
-
-
-
- 66
- 66
- 1.0
- 33
-
-
-
- 75
- 50
- 1.5
- 25
-
-
-
- 90
- 60
- 1.5
- 30
-
-
-
- 100
- 50 [b]
-
- 2
- 25
-
-
-
- 100
- 66
- 1.5
- 33
-
-
-
- 120
- 60
- 2
- 30
-
-
-
- 133
- 66
- 2
- 33
-
-
-
- 150
- 60
- 2.5
- 30 (Intel, AMD)
-
-
-
- 150
- 75
- 2
- 37.5 (Cyrix/IBM 6x86MX)
-
-
-
- 166
- 66
- 2.5
- 33
-
-
-
- 180
- 60
- 3
- 30
-
-
-
- 200
- 66
- 3
- 33
-
-
-
- 233
- 66
- 3.5
- 33
-
-
-
-
- Remarques:
-
-
- [a] 66MHz peut être en fait 66.667MHz, mais ne pas le
- présumer.
-
-
- [b] Le Pentium 100 peut utiliser une horloge externe à
- 50MHz avec un coefficient multiplicateur de 2 ou à 66MHz
- avec un coefficient multiplicateur de 1.5.
-
-
- L'idéal est donc d'avoir un processeur à 100,
- 133, 166, 200 ou 233, sinon qu'avec un coefficient
- multiplicateur de 3 et plus, le processeur attend après
- la mémoire.
-
-
-
-
- Le bogue de l'AMD K6
-
- En 1997, on a rapporté des problèmes d'erreurs d'accès
- à la mémoire lors de compilations intensives avec l'AMD K6.
- Le problème a été réglé au troisième trimestre 97. D'après
- les rapports, les puces K6 dont la date de fabrication est
- “9733” ou plus (i.e., produites à partir de la
- 33ème semaine de 97) n'ont plus ce problème.
-
-
-
-
-
- * 486
-
-
-
-
- * 386
-
-
-
-
- 286
-
- Désolé, FreeBSD ne tourne pas sur des machines 80286. Il est
- quasiment impossible de faire tourner les UNIXs conséquents et
- dotés de fonctionnalités complètes d'aujourd'hui sur de telles
- machines.
-
-
-
-
-
- Mémoire
-
- Il vous faudra au moins 5 MB de mémoire pour pouvoir installer
- FreeBSD. Une fois votre système en état de marche, vous pouvez
- recompiler un noyau
- qui utilisera moins de mémoire. Avec boot4.flp
- vous pouvez vous en sortir avec seulement 4 MB.
-
-
-
-
- * BIOS
-
-
-
-
-
-
- *** Périphériques d'Entrée/Sortie
-
-
-
-
- * Cartes graphiques
-
-
-
-
-
- * Cartes son
-
-
-
-
-
- *** Ports série et cartes multi-ports
-
-
- *** L'UART : Ce que c'est et comment il fonctionne
- &sgml.todo;
-
-
-
-
-
-
- *** Configurer le pilote de périphérique
- <devicename>sio</devicename>
- &sgml.todo;
-
-
-
-
-
- *** Configurer le pilote de périphérique
- <devicename>cy</devicename>
- &sgml.todo;
-
-
-
-
-
-
- * Ports parallèles
-
-
-
-
- * Modems
-
-
-
-
- * Cartes réseau
-
-
-
-
- * Claviers
-
-
-
-
- * Souris
-
-
-
-
- * Autres
-
-
-
-
-
- ** Mémoires de masse
- &trans.a.haby;
-
-
- Utiliser des disques durs ESDI
-
- Copyright © 1995, &a.wilko;. 24 Septembre
- 1995.
-
- ESDI est l'abréviation de Enhanced Small
- Device Interface - Interface
- Améliorée pour les Périphériques
- Légers. Elle se base plus ou moins sur la bonne vieille interface
- ST506/412, initialement conçue par Seagate Technology, le
- fabricant du premier disque Winchester 5.25" bon marché.
-
- L'abréviation précise à juste titre
- ”étendue“. Pour commencer, l'interface est plus
- rapide, 10 ou 15 Mbits/seconde au lieu des 5 Mbits/seconde des disques
- à interface ST412s. Il y a de plus de nouvelles commandes de plus
- haut niveau, qui font que l'interface ESDI est en quelque sorte plus
- “intelligente” que les pilotes de
- périphériques du système d'exploitation. Elle n'est
- cependant pas comparable aux interfaces SCSI. L'ESDI est un standard
- ANSI.
-
- La capacité de disques est accrue parce qu'il y a plus de
- secteurs par piste. Il y a généralement 35 secteurs par
- pistes, mais j'ai vu des disques de grande capacité avec 54
- secteurs par piste.
-
- Bien que l'IDE et le SCSI ait rendu l'ESDI largement
- obsolète, la possibilité de se procurer gratuitement ou
- à peu de frais des disques d'occasion les rend
- intéressants pour les systèmes à budget
- réduit (ou nul).
-
-
- Concepts ESDI
-
-
- Connexions
-
- L'interface ESDI utilise deux câbles par disque. Le
- premier est une nappe à 54 broches qui véhicule les
- signaux de commandes et d'état entre le contrôleur et
- le disque. Les disques sont chaînés en série sur
- ce câble. C'est donc un bus auquel tous les disques sont
- reliés.
-
- Le second câble est une nappe à 20 broches qui
- véhicule les données de et vers le disque. Ce
- câblage est en étoile, chaque disque est donc
- directement relié au contrôleur.
-
- Autant que je sache, on ne peut mettre que deux disques par
- contrôleur ESDI sur un PC. Cela pour des raisons de
- compatibilité (?) avec le standard WD1003 qui n'utilise
- qu'un seul bit pour l'adresse des
- périphériques.
-
-
-
- Adresses des périphériques
-
- Sur chaque câble de commande, il peut y avoir au plus 7
- périphériques et 1 contrôleur. Pour que le
- contrôleur puisse identifier l'adresse de chaque disque, il y
- a sur chaque périphérique ESDI des cavaliers ou des
- interrupteurs pour définir l'adresse du
- périphérique.
-
- Sur les contrôleurs de PC, le premier disque a l'adresse
- 0, et le second l'adresse 1. Vérifiez
- toujours que l'adresse de chaque disque est
- différente ! Sur les PC, où il y a au plus deux
- disques par contrôleur, le premier disque est le disque 0 et
- le second le disque 1.
-
-
-
- Terminaison
-
- Le câble série de commande (rapellez-vous, celui
- à 34 broches) doit être terminé sur le dernier
- disque de la chaîne. Il y a donc sur les disques ESDI une
- résistance de terminaison qui peut être enlevée
- ou désactivée par un cavalier si elle ne doit pas
- servir.
-
- Il n'y a donc qu'un seul disque, celui
- en fin du câble de commande, dont le terminateur doit
- être installé ou activé. Le contrôleur
- termine automatiquement l'autre extrémité du
- câble. Notez bien, s'il vous plaît, que cela implique
- que le contrôleur soit à une extrémité du
- câble, et non au milieu.
-
-
-
-
- Utiliser les disques ESDI avec FreeBSD
-
- Pourquoi est-il si difficile d'arriver à utiliser des
- disques ESDI ?
-
- On dit que ceux qui ont essayé d'utiliser des disques ESDI
- avec FreeBSD ont développé un sentiment de profonde
- frustration. Divers facteurs oeuvrent contre vous et produisent des
- résultats difficiles à comprendre si vous n'y avez
- jamais été confronté.
-
- D'où la légende populaire qui veut que l'ESDI et
- FreeBSD soient définitivement incompatibles. Ce qui suit tente
- de recenser les difficultés et leurs solutions.
-
-
- Les différences de vitesse de l'ESDI
-
- Comme on y a déjà fait allusion, il y a deux
- versions à vitesse différente de l'ESDI. Les disques
- et les contrôleurs plus anciens transfèrent les
- données à 10 Mbits/seconde. Les plus récents le
- font à 15 Mbits/seconde.
-
- Il est facile d'imaginer qu'utiliser des disques à
- 15 Mbits/seconde pose des problèmes avec des
- contrôleurs à 10 Mbits/seconde. Consultez toujours,
- comme d'habitude, la documentation de votre contrôleur
- et celle de votre disque pour vérifier
- qu'ils sont compatibles.
-
-
-
- Restez en piste
-
- Les disques ESDI standards ont de 34 à 36 secteurs par
- piste. La plupart des (anciens) contrôleurs n'acceptent pas
- plus de secteurs que cela. Les disques plus récents, de plus
- grande capacité, ont un plus grand nombre de secteurs par
- piste. Je possède par exemple un disque de 670 Mo qui a 54
- secteurs par piste.
-
- Dans mon cas, le contrôleur ne peut pas gérer
- autant de secteurs. Cela fonctionne en utilisant que 35 secteurs par
- piste. D'où un perte important d'espace disque.
-
- Consultez encore une fois les documentations de votre
- matériel pour plus d'informations. Ne pas respecter les
- spécifications, comme dans mon cas, marchera ou ne marchera
- pas. Essayez ou procurez-vous un contrôleur qui règle
- le problème.
-
-
-
- Secteurs matériels ou logiciels
-
- La plupart des disques ESDI permettent de choisir avec un
- cavalier entre des secteurs matériels ou logiciels. Si les
- secteurs sont matériels, le disque émettera une
- impulsion de début de secteur à chaque nouveau
- secteur. Le contrôleur utilisera cette impulsion pour savoir
- quand commencer à lire ou à écrire.
-
- Il est possible de choisir la taille des secteurs
- matériels (habituellement 256, 512 ou 1024 octets par
- secteur formaté). FreeBSD utilise des secteurs de 512
- octets. Le nombre de secteurs par piste varie aussi, bien qu'on
- utilise toujours le même nombre d'octets par secteur
- formaté. Le nombre d'octets non
- formatés par secteur varie, selon que votre
- contrôleur a besoin de plus ou moins d'octets
- supplémentaires pour fonctionner correctement. Avec plus de
- secteurs par piste, vous aurez bien sûr plus d'espace
- disponible, mais vous pouvez avoir des problèmes si votre
- contrôleur a besoin de plus d'octets que le disque ne peut
- lui en laisser à disposition.
-
- Avec des secteurs logiciels, le contrôleur
- détermine lui-même quand commencer et cesser de lire ou
- écrire. Pour les disques ESDI, les secteurs sont
- matériels par défaut (au moins pour tous ceux que je
- connais). Je n'ai jamais eu besoin d'essayer d'utiliser des secteurs
- logiciels.
-
- Expérimentez avec les secteurs avant d'installer FreeBSD,
- parce que vous devrez refaire un formatage de bas niveau à
- chaque fois.
-
-
-
- Formatage de bas niveau
-
- Il faut faire un formatage de bas niveau des disques ESDI avant
- de pouvoir les utiliser. Il faut les reformater à chaque
- fois que vous modifier la position des cavaliers qui
- déterminent le nombre de secteurs par piste ou l'orientation
- (horizontale, verticale) du disque. Réfléchissez donc
- d'abord, puis formatez. Ne sous-estimez pas le temps
- nécessaire ; pour de gros disques, cela peut prendre des
- heures.
-
- Evitez les utilitaires de formatage de bas niveau qui marquent
- une piste inutilisable dès qu'ils trouvent un secteur
- endommagé. Non seulement cela gaspille de l'espace disque,
- mais cela vous posera peut-être aussi des problèmes
- avec bad144 (voyez plus bas la section sur le
- sujet).
-
-
-
- Correspondances
-
- Les correspondances, bien que ce ne soit pas un problème
- exclusivement réservé à l'ESDI, peuvent vous
- poser de vraies difficultés. Il y a différentes sortes
- de correspondances. Elles ont en commun d'essayer de contourner les
- limites imposées à la géométrie des
- disques par l'architecture d'origine de l'IBM PC/AT (merci
- IBM !).
-
- Il y a tout d'abord la limite bien connue du 1024ème
- cylindre pour le démarrage. Pour qu'un système (quel
- qu'il soit) démarre, le code de démarrage doit se
- trouver quelque part sur les 1024 premiers cylindres. Il n'y a que
- 10 bits disponibles pour coder le numéro de cylindre. Le
- nombre de secteurs est limité à 64 (0-63). Quand vous
- y ajoutez la limite de 16 têtes (aussi liée à
- l'architecture), cela vous donne des disques de taille relativement
- faible.
-
- Pour contourner ce problème, les fabricants de
- contrôleurs ESDI pour PC ont ajouté une extension au
- BIOS en PROM. Cette extension gère les entrées/sorties
- disque au démarrage. (et pour certains systèmes
- d'exploitation, toutes les entrées/sorties) en utilisant des
- correspondances. Par exemple, un gros disque pourra être
- décrit au système comme ayant 32 têtes et 64
- secteurs par piste. De la sorte, le nombre de cylindres sera
- inférieur à 1024, ce qui pourra être
- exploité sans problème. Il faut noter que FreeBSD
- n'utilise le BIOS qu'après que le noyau ait pris le
- contrôle. Nous en dirons plus à ce sujet plus
- loin.
-
- Il faut aussi établir des correspondances avec la plupart
- des BIOS anciens qui ne peuvent gérer que des disques avec
- 17 secteurs par piste (le vieux standard ST412). Les BIOS plus
- récents premettent de définir le type de disque (c'est
- habituellement le type de disque 47).
-
-
- Quoique vous fassiez des correspondances après avoir lu
- ce document, n'oubliez pas que si vous avez plusieurs
- systèmes d'exploitation sur le même disque, ils
- doivent tous utiliser les mêmes correspondances.
-
-
- Pendant que nous en sommes aux correspondances, j'ai vu un
- modèle de contrôleur (mais il y en a probablement
- d'autres) qui permet de diviser un disque en plusieurs partitions
- à l'aide d'une option du BIOS. J'avais choisi 1 disque = 1
- partition, parce que ce contrôleur écrivait cette
- information sur le disque. A la mise sous tension, il la relit et
- transmet au système les informations basées sur ce
- qu'il y a sur le disque.
-
-
-
- Secteurs en réserve
-
- La plupart des contrôleurs ESDI offrent la
- possibilité de réaffecter les secteurs
- défectueux. Pendant ou après le formatage de bas
- niveau du disque, les secteurs défectueux sont marqués
- comme tels, et des secteurs de remplacement prennent (logiquement
- bien sûr) leur place.
-
- Dans la plupart des cas, c'est fait en utilisant N-1 secteurs de
- chaque piste pour les données et le secteur N lui-même
- comme secteur de secours. N est le nombre de secteurs physiquement
- disponibles sur la piste. L'idée est que le système
- d'exploitation voie un disque ”parfait“ sans secteur
- défectueux. Ce n'est pas exploitable dans le cas de
- FreeBSD.
-
- Le problème est que la correspondance entre les
- mauvaix et les bons
- secteurs est effectuée par le BIOS du contrôleur ESDI.
- FreeBSD, qui est un vrai système d'exploitation 32 bits,
- n'utilise pas le BIOS avant d'avoir démarré. Il
- dispose à la place de pilotes de périphérique
- qui dialoguent directement avec le matériel.
-
- Donc, n'utilisez pas les secteurs de réserve,
- la réaffectation des secteurs défectueux, quel que
- soit le nom que lui donne le fabricant de votre contrôleur, si
- vous voulez vous servir du disque avec FreeBSD.
-
-
-
- Gestion des blocs défectueux
-
- La section précédente nous a laissé sur un
- problème. La gestion des blocs défectueux par le
- contrôleur n'est pas exploitable, et FreeBSD suppose
- malgré tout que les supports sont sans défaut. Pour
- résoudre ce problème, FreeBSD utilise l'outil
- bad144. bad144 (dont le nom
- vient du standard de gestion des blocs défectueux de Digital
- Equipment) examine une
- tranche - slice - FreeBSD
- pour détecter les blocs défectueux. Quand il les a
- trouvés, il remplit une table avec les numéros de ces
- blocs à la fin de la tranche.
-
- Quand le disque est en service, les numéros des blocs
- accédés sont comparés à ceux
- stockés dans la table lue sur le disque. Quand un bloc
- demandé est dans la liste de bad144, on
- utilise un bloc de remplacement (aussi en fin de tranche). De cette
- façon, c'est un support ”parfait“ qui est vu par
- les systèmes de fichiers de FreeBSD.
-
- L'utilisation de bad144 présente un
- certain nombre d'inconvénients. En premier lieu, la tranche
- ne peut comporter plus de 126 secteurs défectueux. Si votre
- disque présente un gand nombre de secteurs défectueux,
- vous devrez peut-être le diviser en plusieurs tranches dont
- chacune aura moins de 126 secteurs défectueux. Evitez les
- programmes de formatage de bas niveau qui marquent défectueux
- tous les secteurs d'une piste, dès qu'il y a un
- problème avec la piste. Vous comprennez bien que la limite
- de 126 secteurs est rapidement atteinte avec de tels
- programmes.
-
- En second lieu, si la tranche contient le système de
- fichiers racine, il faut qu'elle soit à l'intérieur
- des 1024 premiers cylindres. La liste bad144 est
- lue au démarrage, en utilisant le BIOS, et cela ne peut
- se faire que si la liste est avant le
- 1025ème cylindre.
-
-
- Ce n'est pas seulement le système
- de fichiers racine qui doit se trouver dans les 1024 premiers
- cylindres, mais toute la tranche qui le
- contient.
-
-
-
-
- Configuration du noyau
-
- Les disques ESDI sont gérés par le même
- pilote wd que les disques IDE et ST412 MFM. Le
- pilote wd devrait fonctionner avec toutes les
- interfaces compatibles WD1003.
-
- La plupart des matériels ont des cavaliers pour
- définir les plages d'adresses d'entrées/sorties et les
- lignes IRQ. Cela vous permet de mettre deux contrôleurs de
- type wd sur un même système.
-
- si votre matériel permet des redéfinition
- non-standard, vous pouvez les utiliser avec FreeBSD, dès lors
- que vous donnez les informations correctes dans le fichier de
- configuration du noyau. Voici une extrait de fichier de
- configuration du noyau ( au fait, ils sont dans
- /sys/i386/conf) :
-
-
-# Premier contrôleur compatible WD
-controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr
-disk wd0 at wdc0 drive 0
-disk wd1 at wdc0 drive 1
-# Second contrôleur compatible WD
-controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr
-disk wd2 at wdc1 drive 0
-disk wd3 at wdc1 drive 1
-
-
-
-
-
- Spécificités de certains matériels ESDI
-
-
- Contrôleurs Adaptec 2320
-
- J'ai réussi à installer FreeBSD sur un disque ESDI
- avec un contrôleur ACB-2320. Il n'y avait pas d'autre
- système d'exploitation sur le disque.
-
- Pour cela, j'ai effectué un formatage de bas niveau du
- disque avec NEFMT.EXE
- (téléchargeable par ftp depuis
- www.adaptec.com) et répondu
- NO à la question qui me demandait si le
- disque devait être formaté en laissant un secteur de
- secours par piste. Le BIOS de l'ACD-2320 était
- désactivé et j'ai utilisé l'option de
- configuration
- libre - free configurable - du
- BIOS du système pour permettre au BIOS de démarrer
- avec.
-
- Avant de me servir de NEFMT.EXE, j'avais
- essayé de formater le disque avec l'utilitaire inclus dans
- le BIOS de l'ACB-2320. Cela s'est avéré inutilisable,
- parce qu'il ne m'a pas proposé de désactiver la
- réservation du secteur de secours. Avec ces derniers,
- l'installation de FreeBSD échoue à l'exécution
- de bad144.
-
- Vérifiez avec soin de quelle variante
- ACB-232xy vous disposez. Le
- x vaut 0 ou
- 2, selon que le contrôleur ne dispose pas
- ou inclut un contrôleur de lecteur de disquettes.
-
- Le y est plus intéressant. C'est un
- blanc, un A-8 ou un D. Le
- blanc indique un contrôleur à 10 Mo/seconde. Le
- A-8 indique un contrôleur à 15
- Mo/seconde capable de gérer 52 secteurs par piste. Le
- D est un contrôleur à 15 Mo/seconde
- qui peut aussi gérer des disques avec plus de 36 secteurs
- par piste (52 aussii ?).
-
- Toutes ces variantes peuvent gérer l'entrelacement 1:1.
- Employez-le, FreeBSD est assez rapide pour s'en accommoder.
-
-
-
- Contrôleurs Western Digital WD1007
-
- J'ai réussi à installer FreeBSD sur un disque ESDI
- avec un contrôleur WD1007. Pour être précis,
- c'était un contrôleur WD1007-WA2. Il y en a d'autres
- variantes.
-
- Pour qu'il fonctionne, j'ai désactivé la
- correspondance entre secteurs et le BIOS du WD1007. Ce qui signifie que je n'ai pas pu me servir de l'utilitaire de formatage de bas
- niveau de ce BIOS. J'ai récupéré
- WDFMT.EXE sur
- www.wdc.com. Il m'a permis de formater
- le disque sans problème.
-
-
-
- Contrôleurs Ultrastor U14F
-
- Selon de nombreux retours sur le réseau, les cartes
- Ultrastor ESDI fonctionnent avec FreeBSD. Je n'ai pas plus
- d'informations sur leur configuration.
-
-
-
-
- Lectures complémentaires
-
- Si vous avez l'intention d'utiliser sérieusement l'ESDI,
- vous devriez avoir la norme officielle à portée de
- main :
-
- Le document le plus récent du comité ANSI X3T10
- est : ”Enhanced Small Device Interface (ESDI)
- [X3.170-1990/X3.170a-1991] [X3T10/792D Rev 11]“.
-
- Le forum Usenet
- comp.periphs est un bon endroit
- ou avoir plus d'informations.
-
- Le World Wide Web (WWW) est aussi
- une excellente source d'informations : Pour les contrôleurs
- Adaptec, consultez
- http://www.adaptec.com/.
- Pour les contrôleurs Western Digital, voyez
- http://www.wdc.com/.
-
-
-
-
- Remerciements à ...
-
- Andrew Gordon pour m'avoir envoyé un contrôleur
- Adaptec 2320 et un disque ESDI pour faire des tests.
-
-
-
-
- Qu'est-ce que le SCSI ?
- &trans.a.brive;
-
- Copyright © 1995, &a.wilko;. July 6,
- 1996.
-
- SCSI est un acronyme pour Small Computer Systems Interface. C'est
- un standard ANSI qui est devenu l'un des premiers bus d'E/S de
- l'industrie informatique. Les bases du standard SCSI proviennent
- de Shugart Associates (les mêmes personnes qui ont donné au monde les
- premiers mini-disques floppy) quand ils ont introduit le bus SASI
- (Shugart Associates Standard Interface).
-
- Un effort industriel a démarré quelque temps plus tard pour
- arriver à un standard plus strict, permettant à des périphériques de
- différents vendeurs de travailler ensemble. Cet effort fut reconnu
- par l'ANSI avec le standard SCSI-1. Ce standard (approx. 1985) devient
- rapidement obsolète. Le standard courant est SCSI-2 (cf Lecture complémentaire),
- avec SCSI-3 en cours de conception.
-
- En plus d'un standard pour l'interconnexion physique, SCSI définit
- un standard logique (jeu de commandes) auxquels les disques doivent
- adhérer. Ce standard "commun" est appellé le Common Command Set (CCS)
- et a été développé plus ou moins en parallèle avec le SCSI-1 ANSI.
- SCSI-2 intègre le CCS (révisé) dans son standard. Les commandes
- dépendent du type de périphérique ; il ne serait pas logique bien
- sûr de définir une commande "Ecriture" pour un scanner.
-
- Le bus SCSI est un bus parallèle, qui supporte plusieurs
- variantes. La plus ancienne et plus utilisée est un bus de 8 bits
- de large, avec des signaux en collecteur ouvert (single-ended),
- transportés sur 50 fils. (Si vous ne savez pas ce que veut dire
- "collecteur ouvert", ne vous en faites pas; c'est justement le sujet
- de ce document). Les architectures modernes utilisent aussi les bus
- de 16 bits avec des signaux différentiels. Cela permet d'obtenir
- des taux de transferts de 20Mo/s, sur des câbles atteignant 25 mètres.
- SCSI-2 permet une largeur maximum du bus de 32 bits en utilisant un
- câble supplémentaire. Rapidement, l'Ultra SCSI (appelé aussi Fast-20)
- et l'Ultra2 (appelé aussi Fast-40) arrivent. Fast-20 correspond à
- 20 millions de transferts par seconde (20Mo/s sur un bus de 8 bits)
- et Fast-40 correspond à 40 millions de transferts par seconde
- (40Mo/s sur un bus de 8 bits). La majorité des disques vendus
- aujourd'hui sont des Ultra SCSI (8 ou 16 bits) en collecteur
- ouvert.
-
- Bien sûr, le bus SCSI n'a pas que des fils de données, mais
- aussi un certain nombre de signaux de contrôle. Un protocole très
- élaboré fait partie du standard pour permettre à plusieurs
- périphériques de se partager le bus de manière efficace.
- En SCSI-2, les données sont toujours vérifiées avec un fil séparé
- pour la parité. Dans l'architecture pré-SCSI-2, la parité était
- optionnelle.
-
- En SCSI-3, des types de bus encore plus rapides sont introduits,
- dont les bus SCSI série qui réduisent l'overhead du cablâge
- (consommation? délai de propagation?)
- et permettent une longueur de bus maximale plus importante.
- Vous pourriez voir des noms comme SSA et FiberChannel dans ce contexte.
- Aucun de ces bus série n'est aujourd'hui d'usage courant (et
- spécialement pas dans l'environnement typique de FreeBSD).
- Pour cette raison, les types de bus série ne seront plus abordés.
-
- Comme vous auriez pu le deviner de la description précédente, les
- périphériques SCSI sont intelligents. Ils doivent l'être pour adhérer
- au standard SCSI (qui est épais de plus de 5 cm). Ainsi, pour un
- disque dur par exemple, vous ne spécifiez pas un tête/cylindre/secteur
- pour adresser un bloc particulier, mais simplement le numéro du
- bloc que vous voulez.
- Des schémas élaborés de cache, des remplacements automatiques de blocs
- défecteux, etc, sont tous rendus possibles par cette approche de
- “périphérique intelligent”.
-
- Sur un bus SCSI, chaque paire possible d'abonnés peut communiquer.
- Que leur fonction le leur permette est une autre chose, mais le
- standard ne le restreint pas. Pour éviter le conflit de signaux,
- les deux abonnés doivent passer par une phase d'arbitrage de bus
- avant de l'utiliser.
-
- La philosophie du SCSI est d'avoir un standard qui permette
- à des périphériques ancien-standard de travailler avec des
- nouveaux-standard. Ainsi, un vieux périphérique SCSI-1 devrait
- normalement fonctionner sur un bus SCSI-2. Je dis normalement, car il
- n'est pas absolument sûr que l'implémentation d'un ancien périphérique
- suive le (vieux) standard de manière assez proche pour être acceptable
- sur un nouveau bus. Les périphériques modernes se comportent bien
- généralement, car la standardisation est devenue plus stricte et
- est mieux respectée par les fabriquants de périphériques.
-
- D'une manière générale, les chances de faire fonctionner
- correctement un ensemble de périphériques sur un seul bus, sont
- meilleures quand tous les abonnés sont SCSI-2 ou plus récents.
- Cela implique que vous n'avez pas besoin de supprimer tous vos vieux
- matériels quand vous venez d'avoir ce magnifique disque de 2Go :
- je possède un système sur lequel un disque pré-SCSI-1, un
- lecteur de cartouche QIC en SCSI-2, un lecteur de cartouches
- hélicoïdal SCSI-1 et 2 disques SCSI-1 fonctionnent assez
- bien ensemble. D'un point de vue des performances, vous
- pourriez toutefois vouloir séparer vos plus vieux périphériques
- des plus nouveaux (=plus rapides).
-
-
-
- Composants SCSI
-
- Comme nous l'avons dit précédemment, les périphériques SCSI sont
- intelligents. L'idée est de mettre les connaissances sur les détails
- intimes du matériel dans le périphérique SCSI lui-même. De cette
- façon, le système hôte n'a pas besoin de se préoccuper de savoir,
- par exemple, combien de têtes possède le disque, ou combien de pistes
- possède tel dérouleur de bandes. Si vous êtes curieux, le standard
- spécifie des commandes avec lesquelles vous pouvez interroger les
- périphériques sur leurs spécificités matérielles. FreeBSD utilise
- cette possibilité pendant le démarrage pour déterminer quels sont
- les périphériques connectés et s'ils ont besoin d'un traitement
- spécial.
-
- L'avantage d'avoir des périphériques intelligents est
- évident : le pilote de périphérique dans l'hôte peut être
- conçu de manière beaucoup plus générique, il n'y a plus besoin de
- modifier (et valider !) les pilotes pour chaque nouveau
- périphérique bizarre qui est introduit.
-
- Pour les câbles et les connecteurs, il y a une règle d'or :
- prenez de la qualité. Avec des vitesses de bus augmentant tout
- le temps, vous vous épargnerez beaucoup de peine en utilisant du
- bon matériel.
-
- Aussi, utilisez des connecteurs plaqués or, des câbles blindés
- et des connecteurs robustes et bien vérrouillés, etc.
- Deuxième règle d'or : n'utilisez pas des câbles plus longs que
- nécessaires. J'ai une fois perdu 3 jours à pourchasser un problème
- sur une machine instable, juste pour découvrir que raccourcir
- le bus SCSI d'un mètre résolvait le problème. Et la longueur
- originale du bus respectait bien les spécifications SCSI.
-
-
-
-
- Types de bus SCSI
-
- D'un point de vue électrique, il existe deux types de bus
- incompatibles : collecteur ouvert (single-ended
- ) et différentiel. Cela signifie qu'il existe deux
- principaux groupes de périphériques et contrôleurs SCSI qui ne peuvent
- être mélangés sur le même bus. Il est toutefois possible d'utiliser
- un convertisseur matériel spécial pour transformer un bus collecteur
- ouvert en différentiel (et vice versa). Les différences entre les
- types de bus sont expliquées dans les sections suivantes.
-
- Dans beaucoup de documentation à propos du SCSI, il existe une
- sorte de jargon en usage pour abréger les différents types de bus.
- Une petite liste :
-
-
-
- FWD : Fast Wide Differential (différentiel large rapide)
-
-
-
- FND : Fast Narrow Differential (différentiel étroit rapide)
-
-
-
- SE : Single Ended (collecteur ouvert)
-
-
-
- FN : Fast Narrow (rapide étroit)
-
-
-
- etc.
-
-
-
-
- Avec un minimun d'imagination, on peut bien imaginer ce que
- cela veut dire.
-
- Large est un peu ambigu, il peut indiquer des bus de 16 ou
- 32 bits. A ma connaissance, la variante en 32 bits n'est pas (encore)
- utilisée, donc normalement large veut dire 16 bits.
-
- Rapide signifie que la cadence sur le bus est un peu différente,
- pour qu'un bus étroit (8 bits) supporte 10 Mo/s au lieu de 5 Mo/s
- pour un SCSI 'lent'. Comme indiqué précédemment, des vitesses de
- bus de 20 et 40 millions de transferts/seconde émergent aussi
- (Fast-20 = Ultra SCSI et Fast40 = Ultra2 SCSI).
-
-
- Les lignes de données > 8 ne sont utilisées que pour les
- transferts de données et l'adressage des périphériques. Les
- transferts des commandes, messages d'état, etc. n'ont lieu que sur
- les 8 bits de poids faibles. Le standard permet aux périphériques
- étroits de fonctionner sur un bus large. La largeur de bus
- utilisable est négociée entre les abonnés. Vous devez regarder
- précisément l'adressage des abonnés lorsque vous mélangez larges
- et étroits.
-
-
-
-
-
-
-
-
- *** Utiliser le SCSI avec FreeBSD
- &sgml.todo
-
-
-
-
-
-
- *** Résoudre les problèmes
- &sgml.todo
-
-
-
-
-
-
- *** Lectures complémentaires
- &sgml.todo
-
-
-
-
-
-
- * Contrôleurs de disques/bandes
-
- * SCSI
-
-
-
- * IDE
-
-
-
- * Disquettes
-
-
-
-
-
- *** Disques durs
-
-
- *** Disques durs SCSI
- &sgml.todo;
-
-
-
-
- * Disques durs IDE
-
-
-
-
-
- *** Contrôleurs de bande
-
-
- *** Commandes générales d'accès aux bandes
-
- &sgml.todo
-
-
-
- *** Interfaces et contrôleurs
- &sgml.todo
-
-
-
- *** Lecteurs SCSI
- &sgml.todo
-
-
-
- * Lecteurs IDE
-
-
-
- * Lecteurs sur contrôleur de disquette
- &sgml.todo
-
-
-
-
-
-
- * Lecteurs sur port parallèle
-
-
-
- *** Informations détaillées
- &sgml.todo
-
-
-
- * Lecteurs posant problème
-
-
-
-
-
- *** Contrôleurs de CD-ROMs
-
- &sgml.todo
-
-
-
-
- * Autres
-
-
-
-
- * Ajouter et reconfigurer des disques
-
-
-
-
-
-
- * Autres
-
-
- * PCMCIA
-
-
-
-
-
diff --git a/fr_FR.ISO8859-1/books/handbook/in-progress.sgml b/fr_FR.ISO8859-1/books/handbook/in-progress.sgml
deleted file mode 100644
index 45248c01c8..0000000000
--- a/fr_FR.ISO8859-1/books/handbook/in-progress.sgml
+++ /dev/null
@@ -1,9 +0,0 @@
-
-
-** Traduction en Cours **
diff --git a/fr_FR.ISO8859-1/books/handbook/internals/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/internals/chapter.sgml
deleted file mode 100644
index 1f05f5a3b5..0000000000
--- a/fr_FR.ISO8859-1/books/handbook/internals/chapter.sgml
+++ /dev/null
@@ -1,2141 +0,0 @@
-
-
-
- Les “internes” de FreeBSD
- &trans.a.haby;
-
-
- Le processus de démarrage
-
- Contribution de &a.phk;. v1.1, 16 Avril
- 1995.
-
- Le démarrage de FreeBSD est essentiellement un processus en
- trois étapes : charger le noyau, identifier le système
- de fichiers racine et initialiser utilisateur. Cela autorise
- d'intéressantes combinaisons décrites plus loin.
-
-
- Charger un noyau
-
- Nous disposons actuellement des trois mécanismes de base
- décrits ci-dessous pour charger un noyau : ils transmettent
- tous des informations au noyau afin de l'aider à décider
- de ce qu'il doit faire ensuite.
-
-
-
- Biosboot
-
-
- Biosboot est notre “code de démarrage”.
- Il consiste en deux fichiers qui seront copiés sur les huit
- premiers kilo-octets de la disquette ou de la
- “tranche” - slice - du
- disque dur à partir de laquelle on démarrera.
-
- Biosboot peut charger un noyau donné par son nom dans
- un système de fichiers FreeBSD.
-
-
-
-
- Dosboot
-
-
- Dosboot a été écrit par DI. Christian
- Gusenbauer, et c'est malheureusement actuellement l'un des
- quelques codes qui ne compilent pas sous FreeBSD, parce qu'il est
- écrit pour les compilateurs Microsoft.
-
- Dosboot peut charger un noyau depuis un fichier MS-DOS ou un
- système de fichiers FreeBSD sur disque. Il essaye de
- négocier avec les divers et étranges
- gestionnires de mémoire qui hantent les adresses hautes des
- systèmes MS-DOS et les gagne en général
- à sa cause.
-
-
-
-
- Netboot
-
-
- Netboot recherche une carte Ethernet supportée et
- utilise BOOTP, TFTP et NFS pour trouver un noyau permettant de
- démarrer.
-
-
-
-
-
-
- Identifier le système de fichiers racine
-
- Dès que le noyau est chargé et que le code de
- démarrage lui passe la main, le noyau s'initialise, il essaie de
- déterminer quels sont les matériels installés, et
- ainsi de suite; il lui faut ensuite trouver le système de
- fichiers racine.
-
- Nous reconnaissons actuellement les types suivants de
- systèmes de fichiers racine :
-
-
-
- UFS
-
-
- C'est le type de système de fichiers racine le plus
- habituel. Il peut être sur disquette ou sur disque
- dur.
-
-
-
-
- MSDOS
-
-
- Bien que ce soit techniquement possible, ce n'est pas
- particulièrement utile, du fait de l'impossibilité
- pour le système de fichiers FAT de
- gérer les liens, les fichiers spéciaux et autres
- particularités “UNIX”.
-
-
-
-
- MFS
-
-
- Il s'agit en rélité d'un système de
- fichiers UFS intégré au noyau à la
- compilation de ce dernier. Cela signifie que le noyau n'a pas
- vraiment besoin de disque dur, disquette ou autre matériel
- pour s'exécuter.
-
-
-
-
- CD9660
-
-
- Cela permet d'utiliser un CD-ROM comme système de
- fichiers racine.
-
-
-
-
- NFS
-
-
- Cela permet d'utiliser un serveur de fichiers comme
- système de fichiers racine, essentiellement pour
- faire fonctionner une machine sans disque dur.
-
-
-
-
-
-
- Initialiser l'environnement utilisateur
-
- Pour que les programmes utilisateur puissent s'exécuter, le
- noyau, quand la phase d'initialisation est terminée, lance un
- processus de pid == 1 et exécute
- un programme du système de fichiers racine;, normalement
- /sbin/init.
-
- Vous pouvez remplacer /sbin/init par n'importe
- quel programme, tant que vous vous rappelez que :
-
- Il n'y a pas de stdin/out/err à moins que vous ne les ouvriez
- vous-même. Si vous sortez du programme, la machine panique. La
- gestion des signaux par le processus de pid == 1 est
- particulière à ce processus.
-
- Le programme /stand/sysinstall de la disquette
- d'installation est un exemple d'“init” adapté.
-
-
-
- Combinaisons intéressantes
-
- Démarrer un noyau contenant un système de fichiers MFS
- avec un programme /sbin/init particulier
- qui...
-
-
-
- A — En utilisant DOS
-
-
-
-
- monte votre disque C: sous le
- répertoire /C:
-
-
-
- attache le fichier spécial
- /dev/vn0 au fichier
- C:/freebsd.fs
-
-
-
- monte /dev/vn0 sous
- /rootfs
-
-
-
- crée les liens symboliques
- /rootfs/bin ->
- /bin,
- /rootfs/etc ->
- /etc,
- /rootfs/sbin ->
- /sbin (etc.)
-
-
-
- Vous faites maintenant tourner FreeBSD sans avoir
- repartitionné votre disque dur...
-
-
-
-
- B — En utilisant NFS
-
-
-
-
- monte avec NFS votre
- serveur:~vous/FreeBSD sur
- /nfs, redéfinit la racine comme
- /nfs - avec
- chroot
- 8 - et
- y exécute /sbin/init
-
-
-
- Vous faites maintenant tourner FreeBSD sans disque dur, bien
- que vous n'ayez pas le contrôle du serveur NFS...
-
-
-
-
- C — Démarre un serveur X
-
-
- Vous avez maintenant un terminal X, bien plus efficace que X
- sous Windows, tellement lent que vous pouvez- voir- tout- ce
- qu'il- fait, alors que votre patron assure que cela est toujours
- mieux que de dépenser encore de l'argent en
- matériel.
-
-
-
-
- D — En utilisant une bande
-
-
-
-
- copie /dev/rwd0 sur un lecteur de
- bandes sur le réseau ou sur un serveur de
- fichiers.
-
-
-
- Vous avez finalement la sauvegarde que vous auriez dû
- faire il y a un an déjà...
-
-
-
-
- E — Fonctionne
- comme coupe-feu / serveur Web / que sais-je
- encore...
-
-
- C'est particulièrement intéressant parce que
- vous pouvez démarrer à partir d'une disquette
- protégée en écriture, et pouvez malgré
- tout écrire sur votre système de fichiers
- racine.
-
-
-
-
-
-
-
- Utilisation de la mémoire du PC
-
- Contribution de &a.joerg;. 16 Avril 1995.
-
- Une brève description de la manière dont
- FreeBSD utilise la mémoire sur les plates-formes
- i386
-
- Le secteur de démarrage est chargé à l'adresse
- 0:0x7c00, et se reloge immédiatement à
- l'adresse 0x7c0:0. (Il n'y a rien de mystérieux
- là-dedans, c'est seulement un ajustement du registre
- %cs, effectué par un
- ljmp.)
-
- Il charge ensuite les quinze premiers secteurs à l'adresse
- 0x10000 (segment BOOTSEG dans le
- Makefile de
- biosboot), et
- initialise la pile pour qu'elle travaille aux adresses en-dessous
- de 0x1fff0. Il passe ensuite au point d'entrée
- boot2 de ce code, i.e. il se branche au-delà de
- lui-même et de la table de partition (fictive), et ajuste le
- registre %cs—nous sommes alors encore en
- mode 16-bits.
-
- boot2 recherche le fichier de démarrage, et
- examine son en-tête a.out. Il masque le point
- d'entrée de ce fichier (habituellement
- 0xf0100000) avec 0x00ffffff et
- charge le code à l'adresse ainsi obtenue. Il est donc
- généralement chargé à l'adresse 1 MB
- (0x00100000). Pendant le chargement, le code va et
- vient entre le mode réel et le mode protégé, pour
- utiliser le BIOS en mode réel.
-
- Le code de démarrage lui-même utilise les
- sélecteurs de segment 0x18 et
- 0x20 pour %cs et
- %ds/%es en mode protégé, et
- 0x28 pour revenir en mode réel. Le noyau est
- finalement lancé avec %cs
- 0x08 et %ds/%es/%ss
- 0x10, qui constituent des descripteurs fictifs
- recouvrant la totalité de l'espace d'adressage.
-
- Le noyau démarre à l'adresse à laquelle il est
- chargé. Comme son édition de liens a été
- effectuée pour une autre adresse (haute), il doit exécuter
- du code PIC jusqu'à ce que la table de pages et
- le répertoire des pages soient correctement renseignés, la
- pagination peut alors être activée et le noyau
- s'exécuter à l'adresse pour laquelle il a été
- généré.
-
- Contribution de &a.dg;. 16 Avril 1995.
-
- Les pages physiques qui suivent immédiatement le segment
- BSS du noyau contiennent le répertoire de pages
- de proc0, ses tables de pages et les
- pages utilisateur. Plus tard, quand le système de
- mémoire virtuelle est initialisé, la mémoire
- physique entre 0x1000-0x9ffff et la mémoire
- physique après le noyau (text+data+bss+proc0+d'autres
- choses) est mise à disposition sous forme de pages de
- mémoire virtuelle ordinaires et ajoutée à la liste
- globales des pages libres.
-
-
-
- L'accès direct à la
- mémoire - -<foreignphrase>DMA</foreignphrase> :
- Qu'est-ce que c'est et comment ça marche
-
- Copyright © 1995,1997 &a.uhclem;, Tous Droits
- Réservés. 10 Décembre 1996. Dernière mise
- à jour le 8 Octobre 1997.
-
- L'accès direct à la
- mémoire - Direct
- Memory Access (DMA) - est une technique qui
- permet que les mouvements de données entre la mémoire et
- les périphériques se fassent sans intervention de
- l'unité centrale (CPU).
-
- L'implémentation de l'accès direct à la
- mémoire diffère selon les architectures matérielles,
- nous limiterons donc la discussion à son implémentation sur
- l'ordinateur personnel IBM (PC), sur l'IBM
- PC/AT, ses successeurs et ses différents clones.
-
- Le sous-système DMA du PC repose sur le contrôleur DMA
- Intel 8237. Ce contrôleur gère quatre canaux DMA qui peuvent
- être programmés séparément et chacun de ces
- canaux peut être le canal actif à un moment donné. Ces
- canaux sont numérotés 0, 1, 2 et 3. Depuis le PC/AT, IBM a
- ajouté une seconde puce 8237, et numéroté ces canaux
- 4, 5, 6 et 7.
-
- Le contrôleur DMA d'origine (0,1, 2 et 3) effectue les
- transferts octet par octet. Le second contrôleur DMA (4, 5, 6 et 7)
- effectue les transferts 16 bits par 16 bits, le premier octet étant
- toujours un octet d'adresse paire. Les deux contrôleurs sont des
- composants identiques, la différence dans la taille des transferts
- vient du càblage différent du second
- contrôleur.
-
- Il y a deux signaux électriques par canal sur le 8237,
- appelés DRQ (Data Request) et -DACK
- (Data Acknowledge). Il y a des signaux supplémentaires dont les noms sont HRQ (Hold
- Request), HLDA (Hold
- Ackwnoledge), -EOP (End Of
- Process) et des signaux de contrôle du bus -MEMR
- (Memory Read), -MEMW (Memory
- Write), -IOR (I/O Read) et
- IOW (I/O Write).
-
- Le contrôleur DMA 8237 est un contrôleur
- “fly-by” - transparent.
- Cela signifie que les données transférées ne
- transitent pas par la puce DMA et n'y sont pas mémorisées.
- En conséquence, le DMA ne peut effectuer de transferts qu'entre un
- port d'entrée/sortie et la mémoire, pas entre deux ports
- d'entrée/sortie ou deux adresses mémoire.
-
-
- Le 8237 autorise l'interconnexion de deux de ses canaux pour
- permettre les opérations DMA de mémoire à
- mémoire, en mode
- non-“fly-by”, mais nul dans
- l'industrie du PC n'utilise cette ressource rare de cette façon,
- parce qu'il est plus rapide de transférer des données
- entre deux adresses mémoire en passant par le processeur.
-
-
- Dans l'architecture PC, chaque canal DMA est normalement activé
- uniquement quand le matériel qui utilise le canal DMA en question
- demande un transfert en validant la ligne DRQ pour ce canal.
-
-
- Un exemple de transfert DMA
-
- Voici un exemple des étapes successives qui provoquent et
- effectuent un transfert DMA. Dans cet exemple, le contrôleur
- du lecteur de disquette - floppy disk
- controller (FDC) - vient de lire un octet sur
- la disquette et demande au DMA de le ranger à l'adresse
- mémoire 0x00123456. Le processus commence
- quand le FDC active le signal DRQ2 (la ligne DRQ pour le canal DMA
- numéro 2) pour prévenir le contrôleur DMA.
-
- Le contrôleur DMA s'aperçoit que le signal DRQ2 est
- positionné et s'assure que le canal DMA 2 est programmé
- et non-masqué (activé). Le contrôleur DMA s'assure
- aussi qu'aucun autre canal DMA n'est actif ou ne demande à
- l'être et possède une plus haute priorité. Ces
- vérifications faites, le DMA demande au processeur de
- libérer le bus pour pouvoir l'utiliser. Il le fait en activant
- le signal HRQ, envoyé au processeur.
-
- Le CPU détecte le signal HRQ et termine l'exécution de
- l'instruction en cours. Dès que le processeur est en mesure de
- libérer le bus, il le fait. Tous les signaux normalement
- générés par le processeur (-MEMR, -MEMW, -IOR,
- -IOW et quelques autres) sont positionnés dans un état
- intermédiaire (ni haut, ni bas), puis le CPU positionne le
- signal HDLA qui prévient le contrôleur DMA qu'il a
- maintenant le contrôle du bus.
-
- Selon le processeur, le CPU peut encore être capable
- d'exécuter quelques instructions supplémentaires bien
- qu'il n'ait plus accès au bus, mais il peut aussi devoir
- attendre lorsqu'il arrive sur une instruction qui doit lire une
- donnée en mémoire et que celle-ci ne se trouve pas dans le
- cache interne du processeur ou dans son
- canal - “pipeline”.
-
- Maintenant que le DMA “a la main”, il active ses signaux
- de sortie -MEMR, -MEMW, -IOR, -IOW, et fixe l'adresse de sortie du DMA
- en 0x3456, adresse qui sera utilisée pour
- diriger l'octet qui va être transféré vers une
- adresse mémoire donnée.
-
- Le DMA avertit ensuite le périphérique qui a
- demandé le transfert que celui-ci commence, en positionnant le
- signal -DACK, ou, dans le cas du contrôleur de disquette, le
- signal -DACK2.
-
- C'est maintenant au contrôleur de disquette de placer l'octet
- à transférer sur les lignes de données du bus. A
- moins qu'il ne faille plus de temps au contrôleur de disquette
- pour placer l'octet de donnée sur le bus (et dans ce cas, il
- prévient le DMA via le signal READY), le DMA attend un cycle de
- son horloge, puis désactive les signaux -MEMW et -IOR, de
- façon à ce que la mémoire bascule et stocke
- l'octet qui se trouve sur le bus, et que le contrôleur de
- disquette sache que l'octet a été
- transféré.
-
- Comme le DMA ne transfère qu'un seul octet à la fois
- et par cycle, le FDC désactive maintenant le signal DRQ2, de
- sorte que le DMA sache que l'on n'a plus besoin de ses services. Le
- DMA désactive alors le signal -DACK2, pour avertir le FDC de
- ne plus mettre de donnée sur le bus.
-
- Le DMA regarde alors si les autres canaux DMA ont des
- opérations à effectuer. Si aucun des canaux n'a sa ligne
- DRQ active, le travail du contrôleur DMA est terminé et il
- positionne ses signaux -MEMR, -MEMW, -IOR, -IOW et d'adresse dans un
- état intermédiaire.
-
- Pour finir, le DMA désactive le signal HRQ. Le CPU s'en
- aperçoit et désactive le signal HOLDA puis active ses
- signaux -MEMR, -MEMW, -IOR, -IOW et d'adresse et enfin reprend
- l'exécution des instructions et ses accès à la
- mémoire et aux périphériques.
-
- Pour un secteur de disquette typique, le processus ci-dessus est
- répété 512 fois, une fois pour chaque octet. Chaque
- fois qu'un octet est transféré, le registre d'adresse du
- DMA est incrémenté et le compteur du DMA qui indique
- combien d'octets ont été transférés,
- décrémenté.
-
- Quand le compteur arrive à zéro, le DMA positionne le
- signal EOP, qui indique que son compteur est nul et qu'aucune autre
- donnée ne sera transférée tant que le
- contrôleur DMA n'aura pas été reprogrammé par
- le CPU. Cet événement est aussi appelé
- “fin de décompte” - Terminal
- Count (TC). Il n'y a qu'un seul signal EOP, et comme il
- ne peut y avoir qu'un seul canal DMA actif à un moment
- donné, c'est nécessairement le canal DMA actuellement
- actif qui vient de terminer sa tâche.
-
- Si un périphérique veut générer une
- interruption à la fin du transfert d'un tampon, il peut tester si
- les signaux -DACKn et EOP sont simultanément actifs. Quand cela
- se produit, c'est que le DMA ne transférera plus d'autre
- donnée pour ce périphérique sans intervention du
- CPU. Le périphérique peut alors positionner un de ses
- signaux d'interruption pour avertir le CPU. Dans l'architecture PC, le
- circuit DMA lui-même ne peut pas générer
- d'interruption. Le périphérique et l'électronique
- associée sont responsables de la génération de
- toutes les interruptions qui peuvent intervenir. Il est en
- conséquence impossible d'avoir des périphériques
- qui utilisent le DMA mais n'emploient pas d'interruptions.
-
- Il est important de comprendre que bien que le CPU laisse toujours
- l'accès au bus au DMA quand le DMA effectue sa demande, cette
- action est transparente pour les applications et pour le
- système d'exploitation, hormis pour le petit temps
- supplémentaire que met le processeur agrave; exécuter des
- instructions quand le DMA est actif. En conséquence, le
- processeur doit interroger les périphériques, les
- registres du DMA ou recevoir une interruption du
- périphérique pour être sûr qu'un transfert DMA
- est terminé.
-
-
-
- Les registres de page DMA et la limite d'adressage de 16Mo
-
- Vous avez peut-être déjà remarqué qu'au
- lieu de prendre pour adresse la valeur 0x00123456, le
- DMA utilise la valeur 0x3456. Cela mérite
- quelques explications.
-
- Quand l'IBM PC d'origine a été conçu, IBM a
- choisi d'utiliser à la fois des circuits contrôleur DMA et
- contrôleur d'interruptions prévus pour le 8085, un
- processeur 8-bits avec un espace adressable sur 16 bits (64Ko). Comme
- l'IBM PC supportait plus de 64Ko de mémoire, il fallait trouver
- le moyen de permettre au DMA de lire ou d'écrire à des
- emplacements mémoire au-delà de la limite de 64Ko. Pour
- résoudre le problème, IBM a ajouté un registre
- externe pour chaque canal DMA qui reçoit les bits de poids fort
- de l'adresse où lire ou écrire. Chaque fois
- qu'un canal DMA est actif, le contenu de ce registre est écrit
- sur le bus d'adresse et y reste jusqu'à ce que l'opération
- DMA pour ce canal soit terminée. IBM a appelé ces
- registres “registres de page”.
-
- Dans notre exemple précédent donc, le DMA mettrait la
- partie 0x3456 de l'adresse sur le bus et le registre
- de page du canal DMA 2 mettrait la partie 0x0012xxxx
- sur le bus. Ensemble, ces deux valeurs constituent l'adresse
- mémoire complète de l'accès.
-
- Comme le registre de page est indépendant du circuit DMA, la
- zone mémoire où lire ou écrire ne doit pas franchir
- la limite d'une plage de 64Ko. Par exemple, si le DMA accède
- à l'adresse 0xffff, après transfert, le
- DMA incrémente le registre d'adresse et accède à
- l'octet d'adresse suivante 0x0000 et non
- 0x10000. Ce n'est probablement pas le résultat
- attendu.
-
-
- Les limites “physiques” de 64Ko ne doivent pas
- être confondues avec les “segments” de 64Ko du mode
- 8086, qui sont définis par l'addition d'un registre de segment
- et d'un registre de déplacement. Les registres de page ne
- peuvent pas recouvrir d'adresses communes car ils font l'objet d'un
- OU logique avec l'adresse basse.
-
-
- Pour compliquer encore les choses, les registres externes d'adresse
- DMA du PC/AT n'ont que 8 bits, ce qui nous donne 8+16=24 bits, ce qui
- signifie que le DMA ne peut adresser la mémoire qu'entre 0 et
- 16Mo. Sur les ordinateurs plus récents, qui permettent d'utiliser
- plus de 16Mo de mémoire, le DMA compatible PC standard ne peut
- adresser au-delà de 16Mo.
-
- Pour contourner cette restriction, les systèmes
- d'exploitation réservent une zone de mémoire en
- dessous de 16Mo qui n'inclue pas une limite de plage de 64 Ko. Le DMA
- est alors programmé pour effectuer les transferts dans cette zone
- tampon. Une fois que ce transfert est terminé, le système
- d'exploitation copie alors les données à l'adresse
- où elles doivent effectivement être stockées.
-
- Pour transférer des données d'une adresse
- au-delà de 16Mo vers un périphérique utilisant le
- DMA, les données doivent d'abord être copiées dans
- un tampon en dessous de 16Mo, et de là, le DMA peut les
- transférer au périphérique. Sous FreeBSD, ces
- tampons réservés sont appelés “tampons
- à rebonds” - Bounce
- Buffers. Dans le monde MS-DOS, ils sont parfois
- appelés “tampons
- intelligents” - Smart
- Buffers.
-
-
- Une nouvelle implémentation du 8237, appelée 82374,
- possède des registres de page de 16 bits, ce qui permet
- l'adressage 32 bits, sans avoir à utiliser de tampon à
- rebonds.
-
-
-
-
- Modes opératoires et configurations du DMA
-
- Le DMA 8237 peut opérer selon différents modes. Les
- principaux sont :
-
-
-
- Simple
-
-
- Un seul octet (ou mot) est transféré. Le DMA
- doit libérer et réobtenir le bus pour chaque nouvel
- octet. Ce mode est habituellement utilisé par les
- périphériques qui ne peuvent transférer
- immédiatement un bloc entier de données. Le
- périphérique fait appel au DMA chaque fois qu'il est
- prêt à un nouveau transfert.
-
- Le contrôleur de disquette standard des compatibles PC
- (NEC 765) n'a qu'un tampon d'un octet. Il utilise donc ce
- mode.
-
-
-
-
- Bloc/A la Demande
-
-
- Une fois que le DMA a eu le contrôle du bus
- système, il transfère un bloc entier de
- données, de 64Ko au plus. Si le périphérique
- a besoin de plus de temps, il peut activer le signal READY pour
- suspendre brièvement le transfert. READY doit être
- utilisé parcimonieusement et, pour un
- périphérique lent, il faut plutôt utiliser le
- mode simple.
-
- Le différence entre les modes Bloc et A la Demande est
- que dès qu'un transfert Bloc est entamé, il se
- poursuit jusqu'à ce que le compteur d'octets
- transférés atteigne la valeur zéro. Le signal
- DRQ ne doit être actif que jusqu'à ce que le signal
- -DACK soit activé. En mode A la Demande, les octets sont
- transférés jusqu'à ce que le signal DRQ soit
- désactivé, le DMA interrompt alors le transfert et
- rend le contrôle du bus au CPU. Quand le signal DRQ est
- ensuite réactivé, le transfert reprend là
- où il a été interrompu.
-
- Les anciens contrôleurs de disques durs utilisaient le
- mode A la Demande, jusqu'à ce que la puissance des
- processeurs augmente au point qu'il soit plus efficace de
- transférer les données en utilisant le CPU, en
- particulier lorsque les adresses mémoire utilisées
- pour le transfert se situent au-delà de la limite des
- 16Mo.
-
-
-
-
- Cascade
-
-
- Ce mécanisme permet à un canal DMA de
- prendre le contrôle du bus, mais c'est ensuite le
- périphérique associé et non le DMA qui est
- chargé de paramétrer le bus d'adresse. Ce mode est
- aussi utilisé pour mettre en oeuvre une technique
- appelée “Maîtrise du
- bus” - Bus
- Mastering.
-
- Quand un canal DMA en mode Cascade reçoit le
- contrôle du bus, le DMA ne met pas les adresses et les
- signaux de contrôle des entrées/sorties sur le bus
- comme le DMA le fait normalement quand il est actif. Au lieu de
- cela, il positionne uniquement le signal -DACK pour le canal
- DMA actif.
-
- C'est au périphérique relié
- à ce canal DMA de fournir l'adresse et les signaux de
- contrôle du bus. Le périphérique
- contrôle alors intégralement le bus système
- et peut effectuer des opérations de lecture et/ou
- d'écriture à n'importe quelle adresse en dessous de
- 16 Mo. Quand le périphérique en a terminé,
- il désactive le signal DRQ et le contrôleur DMA peut
- alors rendre le main au processeur ou à un autre canal
- DMA.
-
- Le mode Cascade peut servir à mettre plusieurs
- contrôleurs DMA en série, et c'est exactement
- à cela que sert le canal DMA 4 dans l'architecture PC.
- Quand un périphérique demande le bus sur un des
- canaux DMA 0, 1, 2 ou 3, le contrôleur DMA esclave active
- le signal HLDREQ, mais ce dernier est en fait relié
- à la ligne DRQ4 du contrôleur DMA primaire et non au
- processeur. Le contrôleur DMA primaire, pensant qu'il a
- un transfert à effectuer sur le canal 4, demande le bus au
- processeur avec le signal HLDREQ. Une fois que le CPU lui a
- octroyé le bus, le signal -DACK4 est positionné et
- ce dernier est en fait relié au signal HLDA du
- contrôleur DMA esclave. Le contrôleur DMA esclave
- transfère alors des données pour le canal DMA
- (0, 1, 2 ou 3) qui l'a demandé ou bien confie le bus
- à un périphérique qui veut en avoir la
- maîtrise, un contrôleur SCSI, par exemple.
-
- A cause de ce câblage, seuls les canaux DMA 0, 1, 2, 3,
- 5, 6 et 7 peuvent être utilisés par des
- périphériques sur les systèmes PC/AT.
-
-
- Le canal DMA 0 était réservé pour les
- opérations de rafraîchissement sur les premiers
- IBM PC, mais est habituellement disponible pour les
- périphériques sur les systèmes
- récents.
-
-
- Quand un périphérique prend le contrôle du
- bus, il faut qu'il transfère des données de ou vers
- la mémoire de façon constante, tant qu'il garde le
- contrôle du bus système. Si le
- périphérique ne peut pas le faire, il faut qu'il
- libère fréquemment le bus, pour que le
- système puisse rafraîchir la mémoire.
-
- La RAM dynamique utilisée par tous les PCs doit
- être rafraîchie fréquemment pour que les bits
- stockés par ses composants restent
- “chargés”. La RAM dynamique est essentiellement constituée de millions de condensateurs représentant
- chacun un bit de donnée. Ces condensateurs sont
- chargés pour représenter un 1 ou
- déchargés pour représenter un
- 0. Comme tous les condensateurs fuient, il faut
- les recharger à intervalles réguliers pour conserver
- les valeurs 1. Les circuits de mémoire
- s'occupent en fait de la tâche de recharger les cases
- mémoire appropriées, mais le reste du système
- doit leur dire quand le faire, pour que cela n'interfère
- pas avec les accès normaux du système à la
- mémoire. Si l'ordinateur ne peut pas rafraîchir la
- mémoire, le contenu de cette dernière sera corrompu
- en quelques millisecondes.
-
- Comme les cycles de lecture et d'écriture en
- mémoire “comptent” pour des cycles de
- rafraîchissement (un cycle de rafraîchissement de la
- RAM dynamique est en fait un cycle de lecture incomplet), tant que
- le périphérique continue de lire ou d'écrire
- des données en séquence en mémoire, cette
- opération rafraîchit la totalité de la
- mémoire.
-
- La prise de contrôle du bus est utilisée par les
- interfaces SCSI et d'autres contrôleurs de
- périphérique de haute performance.
-
-
-
-
- Autoinitialisation
-
-
- Dans ce mode, le DMA opère des transferts d'octet, de
- bloc, ou à la demande mais, lorsque le compteur de
- transferts du DMA arrive à zéro, le compteur et
- l'adresse sont réinitialisés avec les valeurs
- initialement programmées pour le canal DMA. Cela signifie
- que tant que le périphérique demande des transferts,
- ils lui sont accordés. C'est au processeur de placer les
- données à l'avance dans le tampon fixe d'où
- le DMA les déplacera lors d'opérations de sortie, et
- de lire les données du tampon avant que le DMA n'y
- réécrive lors d'opérations
- d'entrée.
-
- Cette technique est couramment utilisée par les
- périphériques audio qui n'ont qu'un petit ou pas
- de tampon matériel pour les échantillons.
- Il y a occupation supplémentaire du processeur pour
- gérer ce tampon “circulaire” mais, dans
- certains cas, c'est la seule façon d'éliminer le
- temps de latence qui intervient lorsque le compteur du DMA
- arrive à zéro et que le DMA arrête le
- transfert jusqu'à ce qu'il soit reprogrammé.
-
-
-
-
-
-
- Programmation du DMA
-
- Le canal DMA qui va être programmé doit toujours
- être “masqué” avant de le paramétrer.
- Cela parce que le matériel pourrait inopinément activer
- le signal DRQ pour ce canal avant que tous les paramètres n'aient
- été chargés ou mis à jour.
-
- Une fois masqué, le processeur doit préciser le sens
- du transfert (de la mémoire vers le périphérique
- ou du périphérique vers la mémoire), le mode
- d'opération du DMA (Simple, Bloc, A la Demande, Cascade, etc.)
- qui sera utilisé pour le transfert et, pour finir, l'adresse et
- le volume de données à transférer. La
- quantité de données à indiquer est
- inférieure d'un octet à celle que vous voulez que le DMA
- transfère. Le LSB (octet bas) et le MSB (octet haut) de l'adresse
- et de la quantité sont écrites sur le même port
- d'entrée/sortie 8 bits, il y a donc un autre
- port sur lequel il faut écrire d'abord pour s'assurer que le
- DMA comprenne le premier octet comme le LSB et le second comme le MSB
- de la quantité et de l'adresse.
-
- Enfin, il faut mettre à jour le registre de page, qui est
- externe au DMA et est accessible via un autre jeu de ports
- d'entrée/sortie.
-
- Une fois que toutes ces valeurs sont définies, le canal DMA
- peut être démasqué. Le canal DMA en question est
- maintenant considéré “armé”, et
- répondra quand la ligne DRQ correspondante sera
- activée.
-
- Reportez-vous à un manuel documentant le matériel
- pour connaître les détails de la programmation du 8237.
- Vous aurez aussi besoin de la carte des ports d'entré/sortie des
- systèmes PC, qui donne les adresses des ports du DMA et du
- registre de page. Vous trouverez ci-dessous une table donnant une
- description complète de ces ports.
-
-
-
- Ports DMA
-
- Les contrôleurs DMA sont situés sur les mêmes
- ports d'entrée/sortie sur tous les systèmes de type IBM-PC
- et PC/AT. La table ci-dessous en donne la liste complète. Les
- ports affectés au deuxième contrôleur DMA ne sont
- pas définis sur les systèmes non-AT.
-
-
- 0x00–0x0f Contrôleur numéro 1 (Canaux 0, 1, 2
- et 3)
-
- Registres d'adresse et compteur DMA
-
-
-
-
-
- 0x00
- écriture
- Adresse initiale Canal 0
-
-
-
- 0x00
- lecture
- Adresse courante Canal 0
-
-
-
- 0x01
- écriture
- Compteur initial Canal 0
-
-
-
- 0x01
- lecture
- Compteur courant Canal 0
-
-
-
- 0x02
- écriture
- Adresse initiale Canal 1
-
-
-
- 0x02
- lecture
- Adresse courante Canal 1
-
-
-
- 0x03
- écriture
- Compteur initial Canal 1
-
-
-
- 0x03
- lecture
- Compteur courant Canal 1
-
-
-
- 0x04
- écriture
- Adresse initiale Canal 2
-
-
-
- 0x04
- lecture
- Adresse courante Canal 2
-
-
-
- 0x05
- écriture
- Compteur initial Canal 2
-
-
-
- 0x05
- lecture
- Compteur courant Canal 2
-
-
-
- 0x06
- écriture
- Adresse initiale Canal 3
-
-
-
- 0x06
- lecture
- Adresse courante Canal 3
-
-
-
- 0x07
- écriture
- Compteur initial Canal 3
-
-
-
- 0x07
- lecture
- Compteur courant Canal 3
-
-
-
-
-
- Registres de commande du DMA
-
-
-
-
-
- 0x08
- écriture
- Registre de commande
-
-
-
- 0x08
- lecture
- Registre d'état
-
-
-
- 0x09
- écriture
- Registre de requête
-
-
-
- 0x09
- lecture
- -
-
-
-
- 0x0a
- écriture
- Registre de masque de bit
-
-
-
- 0x0a
- lecture
- -
-
-
-
- 0x0b
- écriture
- Registre de mode
-
-
-
- 0x0b
- lecture
- -
-
-
-
- 0x0c
- écriture
- Remise à zéro du LSB/MSB de la
- bascule
-
-
-
- 0x0c
- lecture
- -
-
-
-
- 0x0d
- écriture
- Remise à zéro/réinitialisation
- maître
-
-
-
- 0x0d
- lecture
- Registre temporaire (non disponible sur les versions
- récentes)
-
-
-
- 0x0e
- écriture
- Registre de remise à zéro du masque
-
-
-
- 0x0e
- lecture
- -
-
-
-
- 0x0f
- écriture
- Registre d'écriture de tous les bits du
- masque
-
-
-
- 0x0f
- lecture
- Registre de lecture de tous les bits du masque (Intel
- 82374 uniquement)
-
-
-
-
-
-
-
- 0xc0–0xdf Contrôleur numéro 2 (Canaux 4, 5, 6
- et 7)
-
- Registres d'adresse et compteur DMA
-
-
-
-
-
- 0xc0
- ériture
- Adresse initiale Canal 4
-
-
-
- 0xc0
- lecture
- Adresse courante Canal 4
-
-
-
- 0xc2
- écriture
- Compteur initial Canal 4
-
-
-
- 0xc2
- lecture
- Compteur courant Canal 4
-
-
-
- 0xc4
- écriture
- Adresse initiale Canal 5
-
-
-
- 0xc4
- lecture
- Adresse courante Canal 5
-
-
-
- 0xc6
- écriture
- Compteur initial Canal 5
-
-
-
- 0xc6
- lecture
- Compteur courant Canal 5
-
-
-
- 0xc8
- écriture
- Adresse initiale Canal 6
-
-
-
- 0xc8
- lecture
- Adresse courante Canal 6
-
-
-
- 0xca
- écriture
- Compteur initial Canal 6
-
-
-
- 0xca
- lecture
- Compteur courant Canal 6
-
-
-
- 0xcc
- écriture
- Adresse initiale Canal 7
-
-
-
- 0xcc
- lecture
- Adresse courante Canal 7
-
-
-
- 0xce
- écriture
- Compteur initial Canal 7
-
-
-
- 0xce
- lecture
- Compteur courant Canal 7
-
-
-
-
-
- Registres de commande du DMA
-
-
-
-
-
- 0xd0
- écriture
- Registre de commande
-
-
-
- 0xd0
- lecture
- Registre d'état
-
-
-
- 0xd2
- écriture
- Registre de requête
-
-
-
- 0xd2
- lecture
- -
-
-
-
- 0xd4
- écriture
- Registre de masque de bit
-
-
-
- 0xd4
- lecture
- -
-
-
-
- 0xd6
- écriture
- Registre de mode
-
-
-
- 0xd6
- lecture
- -
-
-
-
- 0xd8
- écriture
- Remise à zéro du LSB/MSB de la
- bascule
-
-
-
- 0xd8
- lecture
- -
-
-
-
- 0xda
- écriture
- Remise à zéro/réinitialisation
- maître
-
-
-
- 0xda
- lecture
- Registre temporaire (non disponible sur l'Intel
- 82374)
-
-
-
- 0xdc
- écriture
- Registre de remise à zéro du masque
-
-
-
- 0xdc
- lecture
- -
-
-
-
- 0xde
- écriture
- Registre d'écriture de tous les bits du
- masque
-
-
-
- 0xdf
- lecture
- Registre de lecture de tous les bits du masque (Intel
- 82374 uniquement)
-
-
-
-
-
-
-
- 0x80–0x9f Registres de page du DMA
-
-
-
-
-
- 0x87
- lecture/écriture
- Canal 0 octet bas (23-16) du registre de page
-
-
-
- 0x83
- lecture/écriture
- Canal 1 octet bas (23-16) du registre de page
-
-
-
- 0x81
- lecture/écriture
- Canal 2 octet bas (23-16) du registre de page
-
-
-
- 0x82
- lecture/écriture
- Canal 3 octet bas (23-16) du registre de page
-
-
-
- 0x8b
- lecture/écriture
- Canal 5 octet bas (23-16) du registre de page
-
-
-
- 0x89
- lecture/écriture
- Canal 6 octet bas (23-16) du registre de page
-
-
-
- 0x8a
- lecture/écriture
- Canal 7 octet bas (23-16) du registre de page
-
-
-
- 0x8f
- lecture/écriture
- Octet bas rafraîchissement de page
-
-
-
-
-
-
-
- 0x400–0x4ff Registres du DMA Etendu 82374
-
- Le composant système EISA - EISA
- System Component (ESC) - Intel 82374 est
- apparu au début de 1996 et comporte un contrôleur DMA
- qui fournit un sur-ensemble des fonctionnalités du 8237 en
- même temps que d'autres composants périphériques
- compatibles PC de base sur une seule puce. Ce composant est
- destiné à la fois aux plates-formes EISA et PCI et
- offre des fonctionnalités DMA récentes telles que
- dispersion/regroupement, tampons en anneau et accès direct
- via le DMA à la totalité de l'espace d'adressage sur 32
- bits.
-
- Lorsque ces possibilités sont utilisées, il faut
- aussi fournir le code qui procure les mêmes
- fonctionnalités aux ordinateurs compatibles PC des 16
- années précédentes. Pour des raisons de
- compatibilité, il faut programmer certains registres du 82374
- après avoir programmé les registres
- traditionnels du 8237, pour chaque transfert. Ecrire dans un registre
- 8237 traditionnel remet à zéro certains registres
- étendus du 82374 de façon à assurer la
- rétro-compatibilité du logiciel.
-
-
-
-
-
- 0x401
- lecture/écriture
- Canal 0 octet haut (23-16) du compteur de mots
-
-
-
- 0x403
- lecture/écriture
- Canal 1 octet haut (23-16) du compteur de mots
-
-
-
- 0x405
- lecture/écriture
- Canal 2 octet haut (23-16) du compteur de mots
-
-
-
- 0x407
- lecture/écriture
- Canal 3 octet haut (23-16) du compteur de mots
-
-
-
- 0x4c6
- lecture/écriture
- Canal 5 octet haut (23-16) du compteur de mots
-
-
-
- 0x4ca
- lecture/écriture
- Canal 6 octet haut (23-16) du compteur de mots
-
-
-
- 0x4ce
- lecture/écriture
- Canal 7 octet haut (23-16) du compteur de mots
-
-
-
- 0x487
- lecture/écriture
- Canal 0 octet haut (23-16) du registre de page
-
-
-
- 0x483
- lecture/écriture
- Canal 1 octet haut (23-16) du registre de page
-
-
-
- 0x481
- lecture/écriture
- Canal 2 octet haut (23-16) du registre de page
-
-
-
- 0x482
- lecture/écriture
- Canal 3 octet haut (23-16) du registre de page
-
-
-
- 0x48b
- lecture/écriture
- Canal 5 octet haut (23-16) du registre de page
-
-
-
- 0x489
- lecture/écriture
- Canal 6 octet haut (23-16) du registre de page
-
-
-
- 0x48a
- lecture/écriture
- Canal 7 octet haut (23-16) du registre de page
-
-
-
- 0x48f
- lecture/écriture
- Octet haut rafraîchissement de page
-
-
-
- 0x4e0
- lecture/écriture
- Canal 0 registre Stop (bits 7-2)
-
-
-
- 0x4e1
- lecture/écriture
- Canal 0 registre Stop (bits 15-8)
-
-
-
- 0x4e2
- lecture/écriture
- Canal 0 registre Stop (bits 23-16)
-
-
-
- 0x4e4
- lecture/écriture
- Canal 1 registre Stop (bits 7-2)
-
-
-
- 0x4e5
- lecture/écriture
- Canal 1 registre Stop (bits 15-8)
-
-
-
- 0x4e6
- lecture/écriture
- Canal 1 registre Stop (bits 23-16)
-
-
-
- 0x4e8
- lecture/écriture
- Canal 2 registre Stop (bits 7-2)
-
-
-
- 0x4e9
- lecture/écriture
- Canal 2 registre Stop (bits 15-8)
-
-
-
- 0x4ea
- lecture/écriture
- Canal 2 registre Stop (bits 23-16)
-
-
-
- 0x4ec
- lecture/écriture
- Canal 3 registre Stop (bits 7-2)
-
-
-
- 0x4ed
- lecture/écriture
- Canal 3 registre Stop (bits 15-8)
-
-
-
- 0x4ee
- lecture/écriture
- Canal 3 registre Stop (bits 23-16)
-
-
-
- 0x4f4
- lecture/écriture
- Canal 5 registre Stop (bits 7-2)
-
-
-
- 0x4f5
- lecture/écriture
- Canal 5 registre Stop (bits 15-8)
-
-
-
- 0x4f6
- lecture/écriture
- Canal 5 registre Stop (bits 23-16)
-
-
-
- 0x4f8
- lecture/écriture
- Canal 6 registre Stop (bits 7-2)
-
-
-
- 0x4f9
- lecture/écriture
- Canal 6 registre Stop (bits 15-8)
-
-
-
- 0x4fa
- lecture/écriture
- Canal 6 registre Stop (bits 23-16)
-
-
-
- 0x4fc
- lecture/écriture
- Canal 7 registre Stop (bits 7-2)
-
-
-
- 0x4fd
- lecture/écriture
- Canal 7 registre Stop (bits 15-8)
-
-
-
- 0x4fe
- lecture/écriture
- Canal 7 registre Stop (bits 23-16)
-
-
-
- 0x40a
- écriture
- Canaux 0-3 registre de mode chaînage
-
-
-
- 0x40a
- lecture
- Registre d'état d'interruption du canal
-
-
-
- 0x4d4
- écriture
- Canaux 4-7 registre de mode chaînage
-
-
-
- 0x4d4
- lecture
- Etat du mode chaînage
-
-
-
- 0x40c
- lecture
- Registre de contrôle d'expiration du tampon de
- chaînage
-
-
-
- 0x410
- écriture
- Canal 0 registre de commande
- dispersion/regroupement
-
-
-
- 0x411
- écriture
- Canal 1 registre de commande
- dispersion/regroupement
-
-
-
- 0x412
- écriture
- Canal 2 registre de commande
- dispersion/regroupement
-
-
-
- 0x413
- écriture
- Canal 3 registre de commande
- dispersion/regroupement
-
-
-
- 0x415
- écriture
- Canal 5 registre de commande
- dispersion/regroupement
-
-
-
- 0x416
- écriture
- Canal 6 registre de commande
- dispersion/regroupement
-
-
-
- 0x417
- écriture
- Canal 7 registre de commande
- dispersion/regroupement
-
-
-
- 0x418
- lecture
- Canal 0 registre d'état
- dispersion/regroupement
-
-
-
- 0x419
- lecture
- Canal 1 registre d'état
- dispersion/regroupement
-
-
-
- 0x41a
- lecture
- Canal 2 registre d'état
- dispersion/regroupement
-
-
-
- 0x41b
- lecture
- Canal 3 registre d'état
- dispersion/regroupement
-
-
-
- 0x41d
- lecture
- Canal 5 registre d'état
- dispersion/regroupement
-
-
-
- 0x41e
- lecture
- Canal 6 registre d'état
- dispersion/regroupement
-
-
-
- 0x41f
- lecture
- Canal 7 registre d'état
- dispersion/regroupement
-
-
-
- 0x420-0x423
- lecture/écriture
- Canal 0 registre de pointeur sur le table de descripteurs
- dispersion/regroupement
-
-
-
- 0x424-0x427
- lecture/écriture
- Canal 1 registre de pointeur sur le table de descripteurs
- dispersion/regroupement
-
-
-
- 0x428-0x42b
- lecture/écriture
- Canal 2 registre de pointeur sur le table de descripteurs
- dispersion/regroupement
-
-
-
- 0x42c-0x42f
- lecture/écriture
- Canal 3 registre de pointeur sur le table de descripteurs
- dispersion/regroupement
-
-
-
- 0x434-0x437
- lecture/écriture
- Canal 5 registre de pointeur sur le table de descripteurs
- dispersion/regroupement
-
-
-
- 0x438-0x43b
- lecture/écriture
- Canal 6 registre de pointeur sur le table de descripteurs
- dispersion/regroupement
-
-
-
- 0x43c-0x43f
- lecture/écriture
- Canal 7 registre de pointeur sur le table de descripteurs
- dispersion/regroupement
-
-
-
-
-
-
-
-
-
- La gestion de mémoire virtuelle de FreeBSD
-
- Contribution de &a.dillon;. 6 Février
- 1999
-
-
- Gestion de la mémoire
- physique—<literal>vm_page_t</literal>
-
- La mémoire physique est gérée page par page
- via la structure vm_page_t. Les pages de
- mémoire physique sont caractérisées par
- l'emplacement de leurs structures vm_page_t
- respectives dans l'une des queues de pagination.
-
- Une page peut être verrouillée, active, inactive, dans
- le cache ou libre. Sauf lorsqu'elle est verrouillée, la page est
- typiquement placée dans une queue représentée par
- une liste à double chaînage décrivant l'état
- dans lequel elle est. Les pages verrouillées n'appartiennent
- à aucune queue.
-
- FreeBSD implément système de queues de pagination plus
- sophistiqué pour les pages libres ou dans le cache, de
- façon à mettre en oeuvre un algorithme de coloration des
- pages. Chacun de ces états (libre, caché) met en oeuvre
- des files d'attente multiples selon la taille des caches L1 et L2 du
- processeur. Quand il faut allouer une nouvelle page, FreeBSD essaie d'en
- obtenir une qui soit raisonnablement alignée du point de vue des
- caches L1 et L2 selon le type d'objet en mémoire virtuelle pour
- lequel la page est allouée.
-
- De plus, une page peut être retenue par un compteur
- de référence, ou bloquée avec un compteur
- d'utilisation. Le système de mémoire virtuelle
- implémente aussi un état “verrouillage
- ultime” lorsque la page utilise le bit PG_BUSY des drapeaux de
- page.
-
- En termes généraux, chacune des queues de pagination
- opère en mode LRU (moins récemment utilisé). Une
- page est habituellement initialement placée dans l'état
- actif ou verrouillé. Lorsqu'elle est verrouillée, la page
- est normalement associée à une table de pages quelque
- part. Le système de mémoire virtuelle
- “viellit” les pages en parcourant les pages d'une queue de
- pagination plus active de façon à les déplacer vers
- une queue moins active. Les pages qui sont déplacées vers
- le cache sont toujours associées à un objet en
- mémoire virtuelle mais sont candidates à une
- réutilisation immédiate. Les pages dans la queue libre
- sont vraiment disponibles. FreeBSD essaie de minimiser le nombre de
- pages dans la queue libre, mais il faut conserver un certain nombre de
- pages réellement disponibles pour pouvoir gérer
- l'allocation de pages lors d'interruptions.
-
- Si un processus essaie d'accéder à une page qui
- n'existe pas dans sa table de pages mais existe dans une des queues de
- pagination (la queue inactive ou celle du cache par exemple), il se
- produit un défaut relativement peu pénalisant de
- réactivation de page, qui fait que la page est
- réactivée. Si la page n'existe nulle part en
- mémoire, le processus doit attendre que la page soit
- récupérée sur disque.
-
- FreeBSD optimise dynamiquement ses queues de pagination et essaie de
- maintenir un ratio raisonnable entre les différentes queues de
- même qu'entre les pages à jour et celles qui ne le sont
- pas. Ce rééquilibrage est mis en oeuvre par le
- démon de pagination et comprend le nettoyage des pages
- dégradées (leur synchronisation avec la version en
- arrière-plan), la surveillance des pages
- référencées par des tâches actives (leur
- repositionnement dans les queues LRU ou leur déplacement d'une
- queue à une autre), la migration de pages entre queues lorsque
- les queues sont déséquilibrées, et ainsi de suite.
- Le système de mémoire virtuelle de FreeBSD accepte un
- nombre raisonnable de défauts de réactivation de page afin
- de savoir à quel point une page est active ou inactive. Cela
- permet de prendre de meilleures décisions pour savoir quand
- mettre à jour ou décharger une page sur disque.
-
-
-
- Le tampon cache
- unifié—<literal>vm_object_t</literal>
-
- FreeBSD implémente la notion d'“objet en mémoire
- virtuelle” générique. Les objets en mémoire
- virtuelle peuvent être associés à différents
- types de mise en arrière-plan—non sauvegardé,
- sauvegardé sur disque (swap),
- sauvegardé sur un périphérique physique, ou
- sauvegardé dans un fichier. Comme le système de fichiers
- utilise les mêmes objets en mémoire virtuelle pour
- gérer les informations de base relatives aux fichiers, le
- résultat est un tampon cache unifié.
-
- Les objets en mémoire virtuelle peuvent être des objets
- ombre - shadowed,
- c'est-à-dire qu'ils peuvent être empilés les uns au
- dessus des autres. Par exemple, il peut y avoir un objet ombre
- sauvegardé dans l'espace de swap
- empilé sur un objet sauvegardé dans un fichier pour
- implémenter une correspondance
- mmap
- 2 de type
- MAP_PRIVATE. Ce type d'empilement est aussi
- utilisé pour implémenter différents types de
- partage, dont la copie sur écriture pour les espaces d'adressage
- de processus fils (créés par
- fork 2.
-
- Il faut noter qu'un vm_page_t ne peut être
- associé qu'à un seul objet en mémoire virtuelle
- à la fois. Les objets ombre en mémoire
- virtuelle implémentent le partage apparent de la même page
- pour des instances multiples.
-
-
-
- Entrée/sortie sur le système de
- fichiers—<literal>struct buf</literal>
-
- Les objets en mémoire virtuelle sauvegardés via le
- système de “vnodes”, tels que les objets
- sauvegardés dans des fichiers, doivent généralement
- maintenir eux-mêmes leurs informations d'état à
- jour/périmé, indépendamment de l'idée que
- s'en fait le système de mémoire virtuelle. Par exemple,
- quand le système de mémoire virtuelle décide de
- synchroniser une page physique avec sa version en arrière-plan,
- il doit indiquer que la page est à jour avant qu'elle ne soit
- effectivement écrite en arrière-plan. De plus, les
- systèmes de fichiers doivent être capables de faire
- correspondre des parties d'un fichier ou de méta-informations
- sur un fichier avec l'interface entre la mémoire virtuelle et le
- noyau, pour pouvoir travailler sur ces informations.
-
- Les entités qui servent à gérer cela sont
- appelées tampons du système de fichiers,
- struct bufs, ou encore bps. Quand
- un système de fichiers doit opérer sur une partie d'un
- objet en mémoire virtuelle, il fait typiquement correspondre
- une partie de l'objet à un struct buf puis
- les pages du struct buf à l'interface entre
- la mémoire virtuelle et le noyau. De même, les
- entrées/sorties disque sont typiquement gérées en
- faisant correspondre des parties des objets et des structures tampon
- et en effectuent les entrées/sorties sur ces structures. Les
- vm_page_ts sous-jacentes sont habituellement
- monopolisées le temps des entrées/sorties. Les tampons du
- système de fichiers ont leur propre notion d'occupation, ce qui
- est utile pour le code des pilotes du système de fichiers, qui
- travaille plutôt sur ces tampons que directement sur les pages de
- la mémoire virtuelle.
-
- FreeBSD réserve une quantité limitée de
- l'interface mémoire virtuelle du noyau pour les correspondances
- avec les struct bufs, mais il faut garder à
- l'esprit que cet espace n'est utilisé que pour stocker les
- correspondances et que cela ne diminue pas les possibilités de
- mettre des données dans un cache. Le cache physique de
- données est une fonction des vm_page_ts, et
- non des tampons du système de fichiers. Cependant, comme les
- tampons du système de fichiers sont utilisés pour les
- entrées/sorties, ils limitent de fait le nombre
- d'entrées/sorties possibles simultanément. Comme il y a
- habituellement quelques milliers de tampons de système de
- fichiers disponibles, ce n'est généralement pas un
- problème.
-
-
-
- Tables de correspondance des
- pages—<literal>vm_map_t</literal>,
- <literal>vm_entry_t</literal>
-
- FreeBSD dissocie l'organisation des tables de pages physiques du
- système de mémoire virtuelle. Toutes les tables en dur de
- pages par processus peuvent être reconstruites à la
- volée et sont généralement
- considérées comme jetables. Des tables de pages
- particulières, comme celles qui gèrent l'interface entre
- la mémoire virtuelle et le noyau, sont allouées de
- façon permanente. Ces pages ne sont pas considérées
- comme jetables.
-
- FreeBSD associe des parties des vm_objects
- à des plages d'adresses via les structures
- vm_map_t et vm_entry_t. Les tables
- de pages sont construites synthétiquement à partir de la
- hiérarchie
- vm_map_t/vm_entry_t/vm_object_t.
- Rappelez-vous que j'ai dit que les pages physiques n'étaient
- directement associées qu'à un
- vm_object. Ce n'est en fait pas tout-à-fait
- vrai. Les vm_page_ts sont aussi liés aux
- tables de pages auxquelles ils sont activement associés.
- Un vm_page_t peut être lié à
- plusieurs pmaps, nom que l'on donne aux tables de
- pages. Cependant, l'association hiérarchique fait que toutes les
- références du même objet à la même page
- se rapportent à la même vm_page_t de
- sorte que le tampon cache est globalement unifié.
-
-
-
- Organisation mémoire de l'interface mémoire virtuelle
- du noyau - <foreignphrase>KVM</foreignphrase>
-
- FreeBSD utilise l'interface mémoire virtuelle du noyau pour
- stocker différentes structures de données du noyau.
- L'unique plus grosse entité de cette interface est le tampon
- de cache du système de fichiers. C'est-à-dire, les
- correspondances se rapportant aux struct bufs.
-
- Au contraire de Linux, FreeBSD ne fait pas
- correspondre toute la mémoire physique avec l'interface de
- mémoire virtuelle. Ce qui signifie que FreeBSD peut gérer
- des configurations ayant jusqu'à 4 Go de mémoire sur les
- plates-formes 32 bits. En fait, si l'unité de gestion de la
- mémoire - Memory Management Unit
- (MMU) en était capable, FreeBSD pourrait
- théoriquement gérer jusqu'à 8 To sur une
- plate-forme 32 bits. Nénmoins, comme la plupart des plates-formes
- 32 bits ne peuvent pas recevoir plus de 4 Go, c'est un sujet de
- controverse.
-
- L'interface de mémoire virtuelle du noyau est
- gérée par différents mécanismes. Le
- mécanisme principal de gestion de cette interface est
- l'allocateur de zone - zone allocator.
- L'allocateur de zone prend une portion de l'interface de
- mémoire virtuelle et la découpe en blocs de
- mémoire de même taille pour y allouer un type
- particulier de structure. Vous pouvez utiliser la commande
- vmstat -m pour avoir une vue d'ensemble de
- l'utilisation actuelle de l'interface entre le noyau et la
- mémoire virtuelle zone par zone.
-
-
-
- Optimisation du système de gestion de mémoire
- virtuelle de FreeBSD
-
- Il a été fourni un effort concerté pour que le
- noyau de FreeBSD optimise lui-même dynamiquement son
- fonctionnement. Vous n'avez normalement pas à vous casser la
- tête avec les options maxusers et
- NMBCLUSTERS de configuration du noyau, options de
- compilation habituellement définies dans
- /usr/src/sys/i386/conf/FICHIER_DE_CONFIGURATION.
- On trouve une description de toutes les options de configuration du
- noyau dans /usr/src/sys/i386/conf/LINT.
-
- Lors de la configuration d'un gros système, vous pouvez
- vouloir augmenter maxusers. Ses valeurs sont
- généralement comprises entre 10 et 128. Remarquez que
- donner une valeur trop importante à
- maxusers peut provoquer un débordement de
- l'interface de mémoire virtuelle disponible, entraînant des
- résultats imprévisibles. Il vaut mieux donner à
- maxusers une valeur raisonnable et ajouter d'autres
- options, telles que NMBCLUSTERS, pour augmenter des
- ressources précises.
-
- Si votre système va faire beaucoup appel au réseau,
- vous pouvez augmenter NMBCLUSTERS. Les valeurs
- usuelles sont comprises entre 1024 et 4096.
-
- Le paramètre NBUF est aussi
- traditionnellement utilisé pour dimensionner le système.
- Ce paramètre définit la taille de l'interface de
- mémoire virtuelle du noyau disponible pour les correspondances
- avec les tampons d'entrée/sortie du système de fichiers.
- Notez bien que ce paramètre n'a rien à voir avec le
- tampon cache unifié ! Ce paramètre est
- optimisé dynamiquement par le noyau
- 3.0-current et les noyaux ultérieurs et n'a
- normalement pas besoin d'être ajusté à la main.
- Nous recommandons de ne pas essayer de fixer le
- paramètre NBUF. Laissez le système
- s'en charger. Une valeur trop faible peut rendre le système de
- fichiers largement inefficace et une valeur trop grande saturer les
- queues de pages en entraînant le verrouillage d'un trop grand
- nombre de pages.
-
- Par défaut, les noyaux FreeBSD ne sont pas optimisés.
- Vous pouvez positionner les indicateurs d'optimisation et de
- déboguage avec les directives makeoptions de
- configuration du noyau. Remarquez que vous ne devriez pas utiliser
- l'option à moins que vous ne puissiez vous
- accommoder des noyaux de taille importante (habituellement plus de 7 Mo)
- qui en résultent.
-
-
-makeoptions DEBUG="-g"
-makeoptions COPTFLAGS="-O2 -pipe"
-
-
- sysctl fournit un moyen d'optimiser le noyau en
- temps réel. Vous n'avez habituellement pas à vous
- préoccuper des variables de sysctl, et en
- particulier pas de celles qui concernent la mémoire
- virtuelle.
-
- L'optimisation de la gestion de mémoire virtuelle et du
- système d'exécution est relativement simple. Tout
- d'abord, utilisez “les mises à jour
- logicielles” - softupdates - sur
- vos systèmes de fichiers UFS/FFS chaque fois que c'est possible.
- Le fichier
- /usr/src/contrib/sys/softupdates/README donne
- les indications (et les restrictions) sur la façon de les
- configurer.
-
- En second lieu, prévoyez suffisamment d'espace de pagination.
- Vous devriez avoir une partition de pagination sur chaque disque
- physique, jusqu'à quatre, même sur vos disques “de
- travail”. Il doit y avoir au moins deux fois autant d'espace de
- pagination que de mémoire, et éventuellement même
- plus si vous n'avez pas beaucoup de mémoire. Vous devriez aussi
- dimensionner votre partition de pagination en fonction de la
- quantité maximale de mémoire que vous comptez installer
- sur votre système pour ne pas avoir à repartitionner vos
- disques par la suite. Si vous voulez pouvoir garder une trace en cas
- de plantage - crash
- dump - votre première partition de
- pagination doit être au moins de la taille de la mémoire et
- /var/crash doit disposer de suffisamment de place
- libre pour recevoir la trace.
-
- Il est tout à fait admissible de paginer via NFS à
- partir des systèmes -4.x et ultérieurs,
- mais il faut être conscient que le serveur NFS supportera le plus
- fort de la charge de pagination.
-
-
-
-
-
diff --git a/fr_FR.ISO8859-1/books/handbook/kerneldebug/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/kerneldebug/chapter.sgml
deleted file mode 100644
index b8c33414c3..0000000000
--- a/fr_FR.ISO8859-1/books/handbook/kerneldebug/chapter.sgml
+++ /dev/null
@@ -1,682 +0,0 @@
-
-
-
- Déboguer le noyau
-
- Contribution de &a.paul; et &a.joerg;
- &trans.a.haby;
-
-
- Déboguer une trace de
- plantage - <foreignphrase>crash
- dump</foreignphrase> - avec <command>kgdb</command>
-
- Voici quelques instructions pour déboguer le noyau en cas de
- plantage. Elles supposent que vous avez suffisamment d'espace de
- pagination pour enregistrer la trace du plantage. Si vous avez plusieurs
- partitions de pagination et que la première est trop petite pour
- archiver cette trace, vous pouvez configurer votre noyau pour utiliser
- un autre fichier spécial de périphérique pour stocker
- cette trace (à la ligne config kernel) ou vous
- pouvez indiquer un autre fichier spécial de
- périphérique avec la commande &man.dumpon.8;. La meilleure
- méthode pour utiliser &man.dumpon.8; consiste à positionner
- la variable dumpdev dans
- /etc/rc.conf. Vous utiliserez typiquement une des
- partitions de pagination définies dans
- /etc/fstab. L'enregistrement de la trace sur d'autres
- fichiers spéciaux de périphériques que les partitions
- de pagination, des bandes par exemple, n'est actuellement pas
- supporté. Configurez votre noyau avec config -g.
- Reportez-vous au chapitre Configuration du
- noyau de FreeBSD pour avoir plus de détails sur la
- manière de procéder.
-
- Utilisez la commande &man.dumpon.8; pour dire au noyau où
- enregistrer la trace (notez que cela doit être fait après
- avoir configuré la partition en question comme partition de
- pagination avec &man.swapon.8;). C'est normalement fait via
- /etc/rc.conf et /etc/rc. Vous
- pouvez aussi définir le fichier spécial de trace avec la
- clause dump de la ligne config du
- fichier de configuration du noyau. C'est déprécié
- et ne devrait être utilisé que si vous voulez la trace d'un
- plantage du noyau lors du démarrage du système.
-
-
- Dans ce qui suit, le terme kgdb se rapporte
- à gdb exécuté en “mode
- déboguage du noyau”. Cela se fait soit en lançant
- gdb avec l'option , soit en
- le générant et en le lançant sous le nom
- kgdb. Ce n'est cependant pas fait par défaut,
- et c'est une façon de faire obsolète, parce que les gens
- du projet GNU n'aiment pas que leurs outils se comportent
- différemment quand ils sont appelés d'un autre nom. Cette
- fonctionnalité pourrait disparaître des versions
- futures.
-
-
- Une fois que le noyau a été compilé, faites-en
- une copie, disons kernel.debug, et exécutez
- strip -d sur l'original. Installez l'original comme
- d'habitude. Vous pouvez aussi installer le noyau non expurgé, mais
- le temps de recherche dans la table des symboles augmentera de
- façon dramatique pour certains programmes, et comme le noyau
- est intégralement chargé en mémoire au
- démarrage et y reste ensuite, vous gaspillerez plusieurs Mo de
- mémoire physique.
-
- Si vous testez un nouveau noyau, par exemple en donnant le nom de ce
- noyau au démarrage, mais avez besoin de démarrez avec un
- autre noyau pour avoir de nouveau un système en état de
- marche, démarrez uniquement en mode mono-utilisateur avec
- l'indicateur à l'invite de démarrage et
- effectuez ensuite les étapes suivantes :
-
- &prompt.root; fsck -p
-&prompt.root; mount -a -t ufs # de façon à ce qu'il soit possible d'écrire
- # sur le système de fichiers pour /var/crash
-&prompt.root; savecore -N /kernel.panicked /var/crash
-&prompt.root; exit # ... en mode multi-utilisateur
-
- Cela dit à &man.savecore.8; d'utiliser un autre noyau pour y
- chercher les noms des symboles. Il utiliserait sans cela le noyau en cours
- d'exécution et cela ne ménerait probablement à rien,
- puisque les symboles de la trace de plantage et ceux du noyau ne sont pas
- les mêmes.
-
- Maintenant, après un plantage, allez dans
- /sys/compile/QUELQUE_CHOSE et lancez
- kgdb. Sous kgdb, tapez :
-
- symbol-file kernel.debug
-exec-file /var/crash/kernel.0
-core-file /var/crash/vmcore.0
-
- et voilà, vous pouvez maintenant déboguer la trace de
- plantage en vous servant des sources du noyau comme vous le feriez pour
- n'importe quel autre programme.
-
- Voici la trace d'une session kgdb qui illustre la
- façon de procéder. Les lignes trop longues ont
- été scindées pour en faciliter la lecture, et les
- lignes sont numérotées pour pouvoir y faire
- référence. Malgré cela, c'est un exemple grandeur
- nature, correspondant à une trace prise lors du
- développement du pilote pcvt.
-
- 1:Script started on Fri Dec 30 23:15:22 1994
- 2:&prompt.root; cd /sys/compile/URIAH
- 3:&prompt.root; kgdb kernel /var/crash/vmcore.1
- 4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel
-...done.
- 5:IdlePTD 1f3000
- 6:panic: because you said to!
- 7:current pcb at 1e3f70
- 8:Reading in symbols for ../../i386/i386/machdep.c...done.
- 9:(kgdb) where
-10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767)
-11:#1 0xf0115159 in panic ()
-12:#2 0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698)
-13:#3 0xf010185e in db_fncall ()
-14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073)
-15:#5 0xf0101711 in db_command_loop ()
-16:#6 0xf01040a0 in db_trap ()
-17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723)
-18:#8 0xf019d2eb in trap_fatal (...)
-19:#9 0xf019ce60 in trap_pfault (...)
-20:#10 0xf019cb2f in trap (...)
-21:#11 0xf01932a1 in exception:calltrap ()
-22:#12 0xf0191503 in cnopen (...)
-23:#13 0xf0132c34 in spec_open ()
-24:#14 0xf012d014 in vn_open ()
-25:#15 0xf012a183 in open ()
-26:#16 0xf019d4eb in syscall (...)
-27:(kgdb) up 10
-28:Reading in symbols for ../../i386/i386/trap.c...done.
-29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\
-30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\
-31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\
-32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\
-33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\
-34:ss = -266427884}) (../../i386/i386/trap.c line 283)
-35:283 (void) trap_pfault(&frame, FALSE);
-36:(kgdb) frame frame->tf_ebp frame->tf_eip
-37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done.
-38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\
-39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403)
-40:403 return ((*linesw[tp->t_line].l_open)(dev, tp));
-41:(kgdb) list
-42:398
-43:399 tp->t_state |= TS_CARR_ON;
-44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */
-45:401
-46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200)
-47:403 return ((*linesw[tp->t_line].l_open)(dev, tp));
-48:404 #else
-49:405 return ((*linesw[tp->t_line].l_open)(dev, tp, flag));
-50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */
-51:407 }
-52:(kgdb) print tp
-53:Reading in symbols for ../../i386/i386/cons.c...done.
-54:$1 = (struct tty *) 0x1bae
-55:(kgdb) print tp->t_line
-56:$2 = 1767990816
-57:(kgdb) up
-58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\
-59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126)
-60: return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p));
-61:(kgdb) up
-62:#2 0xf0132c34 in spec_open ()
-63:(kgdb) up
-64:#3 0xf012d014 in vn_open ()
-65:(kgdb) up
-66:#4 0xf012a183 in open ()
-67:(kgdb) up
-68:#5 0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\
-69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\
-70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \
-71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \
-72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673)
-73:673 error = (*callp->sy_call)(p, args, rval);
-74:(kgdb) up
-75:Initial frame selected; you cannot go up.
-76:(kgdb) quit
-77:&prompt.root; exit
-78:exit
-79:
-80:Script done on Fri Dec 30 23:18:04 1994
- Commentaires sur les résultats ci-dessus :
-
-
-
- ligne 6 :
-
-
- C'est une trace obtenue depuis DDB (voir plus bas), d'où
- le commentaire panique “because you said
- to! - parce que vous l'avez
- demandé” - et une assez longue trace de la
- pile d'exécution; la raison initiale du passage sous DDB est
- néanmoins la détection d'un défaut de
- page.
-
-
-
-
- ligne 20 :
-
-
- C'est la position de l'appel à la fonction
- trap() dans la pile.
-
-
-
-
- ligne 36 :
-
-
- Impose l'utilisation d'un nouveau contexte de
- pile - stack frame; ce
- n'est dorénavant plus nécessaire. Les contextes de
- pile sont maintenant censés pointer sur les bonnes adresses,
- même en cas de débranchement. (Je n'ai pas de trace
- récente de plantage sous la main; mon noyau n'a pas
- paniqué depuis un certain temps.) Au vu de la ligne 403 du
- code source, il y a de fortes chances pour que soit le pointeur de
- “tp” soit erronné soit il y ait
- débordement dans le tableau.
-
-
-
-
- ligne 52 :
-
-
- Le pointeur semble suspect, mais il se trouve que l'adresse est
- valide.
-
-
-
-
- ligne 56 :
-
-
- Il pointe cependant sur n'importe quoi, nous avons donc
- trouvé notre erreur! (Pour ceux qui ne sont pas
- familiarisés avec ce code particulier :
- tp->t_line se rapporte à la gestion de
- la liaison - line
- discipline - du périphérique
- console, qui doit être un entier assez petit.)
-
-
-
-
-
-
- Déboguer une trace de plantage avec DDD
-
- Il est aussi possible d'examiner une trace de plantage avec un
- débogueur graphique comme ddd. Ajoutez l'option
- à la ligne de commande de
- ddd que vous utiliseriez normalement. Par
- exemple :
-
- &prompt.root; ddd -k /var/crash/kernel.0 /var/crash/vmcore.0
-
- Vous devriez maintenant pouvoir examiner la trace de plantage avec
- l'interface graphique de ddd.
-
-
-
- Analyser la trace après plantage
-
- Que faire si le noyau plante alors que vous ne l'aviez pas
- prévu et donc que vous ne l'avez pas compilé avec
- config -g ? Tout n'est pas perdu. Ne paniquez
- pas !
-
- Il faut bien sûr que vous autorisiez l'archivage des traces de
- plantage. Voyez plus haut quelles options vous devez utiliser pour
- cela.
-
- Allez dans le répertoire de compilation de votre noyau et
- éditez la ligne contenant COPTFLAGS?=-O.
- Ajoutez-y l'option (mais ne changez
- rien au niveau d'optimisation. Si vous avez
- déjà une vague idée de là où se situe
- le code fautif (e.g., le pilote pcvt dans
- l'exemple précédent), supprimez tous les fichiers objets
- correspondant à ce code. Recompilez le noyau. Du fait de la
- modification de la date du Makefile, d'autres
- objets seront reconstruits, par exemple, trap.o. Avec
- un peu de chance, l'option supplémentaire ne
- changera rien au code généré, vous aurez donc un
- nouveau noyau dont le code est similaire à celui qui a
- planté à l'exception de quelques symboles de
- débogage. Vérifiez au moins les tailles des deux noyaux avec
- la commande &man.size.1;. Si elles ne correspondent pas, vous devrez
- probablement en rester là.
-
- Examinez maintenant la trace comme décrit plus haut. Il y aura
- probablement par endroit des symboles de débogage incomplets, comme
- on peut le voir dans la trace de la pile de l'exemple plus haut, où
- certaines fonctions sont listées sans numéro de ligne et
- liste d'arguments. S'il vous faut plus d'informations, supprimez les
- fichiers objets et reprenez la session kgdb
- jusqu'à ce que vous en sachiez assez.
-
- Il n'y a aucune garantie que tout cela marche, mais cela fera
- l'affaire dans la plupart des cas.
-
-
-
- Déboguer en ligne le noyau avec DDB
-
- Tandis que kgdb comme débogueur hors-ligne
- procure une interface utilisateur de très haut niveau, il y a
- certaines choses qu'il ne peut pas faire. Les principales sont la mise en
- place de points d'arrêt et l'exécution pas -à-pas du
- code du noyau.
-
- Si vous devez faire du débogage de bas niveau de votre noyau,
- il y a un débogueur de bas niveau appelé DDB. Il permet la
- mise en place des points d'arrêt, l'exécution instruction
- par instruction des fonctions du noyau, l'examen et la modification
- de variables du noyau, etc. Il ne peut cependant pas accéder aux
- fichiers source du noyau et n'a accès qu'aux symboles globaux et
- statiques et non à la totalité des informations comme
- kgdb.
-
- Pour configurer votre noyau pour y inclure DDB, ajoutez la ligne
- d'option :
-
-
-options DDB
-
- à votre fichier de configuration et recompilez-le.
- (Reportez-vous au chapitre Configurer le
- noyau de FreeBSD pour plus de détails sur la configuration
- du noyau de FreeBSD.)
-
-
- Si vous avez une ancienne version des blocs de démarrage, les
- symboles du débogueur peuvent ne pas être chargés du
- tout. Mettez à jour les blocs de démarrage; les versions
- récentes chargent automagiquement les symboles de DDB.
-
-
- Une fois que votre noyau incluant DDB s'exécute, il y a
- plusieurs façons de passer sous DDB. La première et la plus
- immédiate est d'utiliser l'option dès le
- démarrage; Le noyau démarrera en mode débogage et
- passera sous DDB avant même de tester la présence des
- périphériques. Vous pouvez donc même déboguer
- les fonctions de test et d'attachement des
- périphériques.
-
- Le seconde est d'utiliser une combinaison de touches du clavier,
- habituellement
- CtrlAlt>Esc.
- Avec syscons, cette combinaison peut être
- redéfinie; certaines redéfinitions distribuées du
- clavier le font, faites-y donc attention. Il existe une option pour les
- consoles série qui permet d'utiliser un Break sur
- la ligne console pour passer sous DDB
- (options BREAK_TO_DEBUGGER dans le fichier de
- configuration du noyau). Ce n'est pas l'option par défaut, parce
- qu'il y a de nombreux adaptateurs série qui génèrent
- gratuitement un Break, par exemple, lorsque l'on
- débranche le câble.
-
- Troisièmement, le noyau passe sous DDB lorsqu'une condition
- panique intervient, s'il est configuré pour l'utiliser. En
- conséquence, il vaut mieux ne pas configurer le noyau pour qu'il
- inclue DDB, si la machine n'est pas sous surveillance.
-
- Les commandes de DDB ressemblent assez à celles de
- gdb. La première chose que vous devrez
- probablement faire sera de placer un point d'arrêt :
-
- b nom-de-fonction
-b adresse
-
- Par défaut, les nombres sont normalement donnés en
- hexadécimal, mais, pour les distinguer des noms de symboles, les
- nombres hexadécimaux qui commencent par les lettres
- a-f doivent être précédés de
- 0x (c'est facultatif pour les autres nombres). On peut
- utiliser des expressions simples, par exemple :
- nom-de-fonction + 0x103.
-
- Pour reprendre l'exécution interrompue du noyau, tapez
- simplement :
-
- c
-
- Pour avoir le trace de la pile d'exécution, tapez :
-
- trace
-
-
- Remarquez que quand vous passez sous DDB avec une combinaison de
- touches, le noyau traite en fait une interruption, le contenu de la pile
- d'exécution ne vous sera alors peut-être pas très
- utile.
-
-
- Si vous voulez supprimer un point d'arrêt, servez-vous
- de :
-
- del
-del expression-définissant-l'adresse
-
- Le premier exemple sert immédiatement après être
- arrivé à un point d'arrêt et supprime ce point
- d'arrêt. Le second exemple permet de supprimer n'importe quel point
- d'arrêt, mais il faut donner son adresse exacte; on peut l'obtenir
- avec :
-
- show b
-
- Pour exécuter pas-à-pas le noyau, essayez :
-
- s
-
- Vous exécuterez ainsi pas-à-pas les fonctions, mais vous
- pouvez aussi faire en sorte que DDB aille jusqu'à l'instruction de
- retour d'une fonction avec :
-
- n
-
-
- Ce n'est pas la même chose que la commande
- next de gdb, mais c'est
- l'équivalent de la commande finish.
-
-
- Pour consulter le contenu de la mémoire, employez (par
- exemple) :
-
- x/wx 0xf0133fe0,40
-x/hd db_symtab_space
-x/bc termbuf,10
-x/s stringbuf
-
- pour accéder à des mots/demi-mots/octets, et pour
- afficher des chaînes de valeurs
- hexadécimales/décimales/caractères. La valeur
- après la virgule est le nombre d'éléments. Pour
- afficher les 0x10 éléments suivants,
- tapez simplement :
-
- x ,10
-
- De même, utilisez :
-
- x/ia foofunc,10
-
- pour désassembler les 0x10 premières
- instructions de foofunc, et les afficher avec leur
- déplacement depuis le début de
- foofunc.
-
- Pour modifer le contenu de la mémoire, utilisez la commande
- d'écriture :
-
- w/b termbuf 0xa 0xb 0
-w/w 0xf0010030 0 0
-
- Le paramètre de la commande
- (b/h/w)
- indique la taille de la valeur à écrire, la première
- expression qui suit est l'adresse où écrire et la suite est
- interprétée comme donnant les valeurs à écrire
- en séquence en mémoire.
-
- Si vous avez besoin de connaître le contenu des registres,
- servez-vous de :
-
- show reg
-
- Vous pouvez aussi afficher la valeur d'un seul registre avec, par
- exemple :
-
- p $eax
-
- et la modifier avec :
-
- set $eax nouvelle-valeur
-
- Si vous voulez appeler une fonction du noyau depuis DDB, dites
- simplement :
-
- call func(arg1, arg2, ...)
-
- La valeur de retour sera affichée.
-
- Pour avoir un résumé du style &man.ps.1; des processus
- lancés, utilisez :
-
- ps
-
- Vous avez maintenant examiné la raison de l'échec de
- votre noyau, et voulez redémarrer le système. Rappelez-vous
- que, selon la gravité des dysfonctionnements
- précédents, toutes les parties du noyau ne fonctionneront
- peut-être pas comme prévu. Redémarrez votre
- système, avec l'un des moyens suivants :
-
- call diediedie()
-
- Votre noyau enregistrera une trace de plantage et redémarrera,
- vous pourrez donc analyser à plus haut niveau la trace avec
- kgdb. Cette commande doit habituellement être
- suivie d'une instruction continue. Il y a maintenant
- un alias pour cela : panic.
-
- call boot(0)
-
- C'est une bonne méthode pour arrêter proprement le
- système, exécuter sync() sur tous les
- disques et ensuite redémarrer. Tant que le disque et les interfaces
- du système de fichier du noyau ne sont pas endommagés, ce
- peut être une bonne façon d'arrêter presque proprement
- le système.
-
- call cpu_reset()
-
- est la méthode ultime pour se sortir du désastre et
- c'est à peu près la même chose que d'appuyer sur le
- Bouton Rouge.
-
- Si vous avez besoin d'un bref résumé des commandes,
- tapez simplemement :
-
- help
-
- Il est néanmoins chaudement recommandé d'avoir sous la
- main un exemplaire des pages de manuel de &man.ddb.4; lors d'une session
- de débogage. Rappelez-vous qu'il peut être difficile de lire
- le manuel en ligne tandis que l'on exécute pas-à-pas le
- noyau.
-
-
-
- Déboguer en ligne le noyau en utilisant GDB à
- distance
-
- Cette fonctionnalité est supportée depuis FreeBSD 2.2,
- et est de fait très élégante.
-
- GDB supporte déjà depuis longtemps le
- débogage à distance. Cela se fait avec
- un protocole très simple sur une ligne série. A l'inverse
- des autres méthode décrite plus haut, il vous faudra pour
- cela deux machines. L'une fournit l'environnement de débogage, y
- compris la totalité des sources, et un exemplaire du binaire du
- noyau incluant tous les symboles, et l'autre est la machine cible qui
- exécute un exemplaire identique du noyau (mais sans les
- informations de débogage).
-
- Vous devrez configurer le noyau en question avec config
- -g, inclure à sa configuration, et
- le compiler comme d'habitude. Cela donne un binaire assez imposant, du
- fait des informations de débogage. Copiez ce noyau sur la machine
- cible, supprimez les informations de débogage avec strip
- -x, et démarrez avec l'option .
- Reliez la première ligne série de la machine cible à
- n'importe quelle ligne série de la machine de débogage.
- Allez maintenant dans le répertoire de compilation du noyau de la
- machine de débogage, et lancez gdb :
-
- &prompt.user; gdb -k kernel
-GDB is free software and you are welcome to distribute copies of it
- under certain conditions; type "show copying" to see the conditions.
-There is absolutely no warranty for GDB; type "show warranty" for details.
-GDB 4.16 (i386-unknown-freebsd),
-Copyright 1996 Free Software Foundation, Inc...
-(kgdb)
-
- Initialisez la session de débogage à distance (en
- supposant que l'on utilise le premier port série)
- avec :
-
- (kgdb) target remote /dev/cuaa0
-
- Puis, sur la machine cible (celle qui est passée sous DDB avant
- même de tester la présence des périphériques),
- tapez :
-
- Debugger("Boot flags requested debugger")
-Stopped at Debugger+0x35: movb $0, edata+0x51bc
-db> gdb
-
- DDB répondra par :
-
- Next trap will enter GDB remote protocol mode
-
- Chaque que vous taperez gdb, vous passerez de GDB
- à distance à DDB en local et inversement. Pour basculer
- immédiatement, tapez simplement s
- (step). Votre GDB hôte aura
- maintenant le contrôle du noyau cible :
-
- Remote debugging using /dev/cuaa0
-Debugger (msg=0xf01b0383 "Boot flags requested debugger")
- at ../../i386/i386/db_interface.c:257
-(kgdb)
-
- Vous pouvez faire sous cette session à peu près les
- mêmes choses qu'avec n'importe quelle autre session GDB, y compris
- accéder intégralement au source, l'exécuter en mode
- gud dans une fenêtre Emacs (ce qui
- provoque l'affichage automatique du code source dans une autre
- fenêtre Emacs), etc.
-
- GDB peut aussi être utilisé à distance pour
- déboguer des modules du noyau à chargement
- dynamique - LKM. Compilez d'abord
- le module avec les symboles de débogage :
-
- &prompt.root; cd /usr/src/lkm/linux
-&prompt.root; make clean; make COPTS=-g
-
- Installez ensuite cette version du module sur la machine cible,
- chargez-le et utilisez modstat pour trouver où
- il a été chargé :
-
- &prompt.root; linux
-&prompt.root; modstat
-Type Id Off Loadaddr Size Info Rev Module Name
-EXEC 0 4 f5109000 001c f510f010 1 linux_mod
-
- Prenez l'adresse de chargement et ajoutez-y 0x20
- (probablement pour prendre en compte l'en-tête a.out). C'est
- l'adresse où le code du module a été relogé.
- Utilisez la commande add-symbol-file de GDB pour
- informer le débogueur de l'existence du module :
-
- (kgdb) add-symbol-file /usr/src/lkm/linux/linux_mod.o 0xf5109020
-add symbol table from file "/usr/src/lkm/linux/linux_mod.o" at
-text_addr = 0xf5109020? (y or n) y
-(kgdb)
-
- Vous avez maintenant accès à tous les symboles du
- module.
-
-
-
- Déboguer un pilote de console
-
- Comme vous avez besoin d'un pilote de console pour faire tourner DDB,
- les choses sont plus compliquées si c'est le pilote de console
- lui-même qui a des problèmes. Vous pouvez penser à
- utiliser une console série (soit avec des blocs de démarrage
- modifiés, soit en utilisant l'option à
- l'invite Boot:) et connecter un terminal standard au
- premier port série. DDB fonctionne avec n'importe quel pilote de
- console configuré, donc bien sûr aussi avec une console
- série.
-
-
-
-
-
diff --git a/fr_FR.ISO8859-1/books/handbook/kernelopts/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/kernelopts/chapter.sgml
deleted file mode 100644
index 7837338269..0000000000
--- a/fr_FR.ISO8859-1/books/handbook/kernelopts/chapter.sgml
+++ /dev/null
@@ -1,200 +0,0 @@
-
-
-
- Ajouter de nouvelles options de configuration du noyau
-
- Contribution de &a.joerg;
- &trans.a.haby;
-
-
- Vous devez être familiarisé avec le chapitre
- Configurer le noyau de FreeBSD avant
- de lire ce chapitre.
-
-
-
- Au fait, qu'est-ce-qu'une <emphasis>option du
- noyau</emphasis> ?
-
- L'utilisation des options du noyau est principalement décrite
- au chapitre Configurer le noyau de
- FreeBSD. Il y a aussi des explications à propos des options
- “historiques” et “nouveau style”. L'objectif final
- est de remplacer toutes les options supportées du noyau par des
- options de nouveau style, de façon à ce que pour ceux qui
- ont correctement exécuté make depend dans
- leur répertoire de compilation du noyau après
- &man.config.8;, la phase de compilation retrouve automatiquement les
- options modifiées et ne recompile que les fichiers
- nécessaires. Il n'y aura alors plus besoin d'effacer tous les
- fichiers de l'ancien répertoire de compilation après
- chaque &man.config.8;, comme c'est encore le cas.
-
- Une option du noyau n'est essentiellement rien de plus que la
- définition d'une macro-instruction du préprocesseur C pour
- la compilation du noyau. Pour que la compilation soit vraiment
- optionnelle, la partie correspondante du source du noyau (ou le fichier
- .h du noyau) doit être écrit avec
- l'option à l'esprit, i.e., la valeur par défaut doit pouvoir
- être surchargée par l'option de configuration. C'est
- habituellement réalisé avec quelque chose
- comme :
-
-
-#ifndef CETTE_OPTION
-#define CETTE_OPTION (une valeur par défaut)
-#endif /* CETTE_OPTION */
-
-
- De la sorte, un administrateur donnant une autre valeur à
- l'option dans son fichier de configuration, désactivera la valeur
- par défaut et la remplacera par sa nouvelle valeur. Bien
- évidemment, la nouvelle valeur sera substituée dans le code
- par le préprocesseur, ce doit donc être une expression C
- valide dans le contexte dans lequel était utilisée la
- valeur par défaut.
-
- Il est aussi possible de définir une option sans valeur qui
- encadre une partie donnée du code pour la mettre en service ou
- non :
-
-
-#ifdef CETTE_OPTION
-
-[votre code]
-
-#endif
-
-
- Simplement indiquer CETTE_OPTION dans le fichier de
- de configuration (avec ou sans valeur) mettra en service le code
- correspondant.
-
- Les gens qui ont l'habitude du langage C auront immédiatement
- compris que n'importe quoi peut être une option de configuration,
- dès lors qu'il y a au moins un #ifdef qui y fait
- référence... Il y a cependant peu de chance que beaucoup
- utilisent :
-
-
-options notyet,notdef
-
- dans leur fichier de configuration, et se demandent ensuite pourquoi
- la compilation du noyau échoue. :-)
-
- A l'évidence, donner n'importe quel nom aux options rend
- très difficile de retrouver où elles sont utilisées
- dans l'arborescence des sources du noyau. C'est la raison d'être de
- l'organisation des options de nouveau style,
- dans laquelle chaque option est définie dans un
- .h distinct du répertoire de compilation du
- noyau, appelé par convention
- opt_foo.h. De cette
- façon, les dépendances habituelles dans le
- Makefile s'appliquent, et make
- peut savoir ce qu'il faut recompiler quand une option a été
- modifiée.
-
- Le mécanisme d'option de style ancien a un avantage dans le cas
- des options locales ou éventuellement expérimentales dont
- la durée de vie prévue est courte : comme il est
- simple d'ajouter un #ifdef au source du noyau, cela
- en fait d'office une option de configuration du noyau. Dans ce cas,
- l'administrateur qui utilise une telle option doit lui-même
- savoir ce que cela implique (et éventuellement forcer la
- recompilation de parties de son noyau). Une fois que toutes les options
- supportées auront été converties, &man.config.8;
- émettra un message d'avertissement toutes les fois qu'une option
- non supportée sera détectée, mais il l'incluera
- malgré tout dans le Makefile du
- noyau.
-
-
-
- Que faut-il donc faire maintenant ?
-
- Editez d'abord sys/conf/options (ou
- sys/i386/conf/options.<arch>,
- e. g., sys/i386/conf/options.i386), et
- sélectionnez le fichier
- opt_foo.h où votre
- option ira le mieux.
-
- S'il y a déjà quelque chose qui se rapproche de
- l'objectif de la nouvelle option, utilisez-le. Par exemple, les options
- qui modifient le comportement général du sous-système
- SCSI vont dans opt_scsi.h. Par défaut, le fait
- d'indiquer une option dans le fichier d'option approprié, disons
- FOO, implique que sa valeur sera définie dans le
- fichier opt_foo.h. Ce peut être
- surchargé dans la partie droite de la règle en indiquant un
- autre nom de fichier.
-
- S'il n'y a pas encore de fichier
- opt_foo.h pour la nouvelle
- option envisagée, inventez un nouveau nom. Faites en sorte qu'il
- soit significatif, et ajoutez des commentaires à la nouvelle
- section du fichier
- options[.<arch>].
- &man.config.8; s'apercevra automagiquement de la modification et
- créera ce fichier la prochaine fois qu'il sera utilisé. La
- plupart des options vont normalement dans un fichier d'en-tête qui
- leur est propre.
-
- Incorporer trop d'options à un même
- opt_foo.h entraînera
- la recompilation de nombreux fichiers du noyau dès qu'une des
- options du fichier de configuration aura été
- modifiée.
-
- Pour finir, déterminez quels fichiers du noyau dépendent
- de la nouvelle option. A moins que vous veniez de l'inventer, et qu'elle
- n'existe encore nulle part :
- &prompt.user; find /usr/src/sys -name type f | xargs fgrep NEW_OPTION
- vous aidera à les trouver. Editez ces fichiers et
- ajoutez-y :
-
-#include "opt_foo.h"
-
- au début, avant tout autre
- #include <xxx.h>. Cet ordre est très
- important, parce que les options peuvent surcharger les valeurs par
- défaut des fichiers inclus habituels, si les valeurs par
- défaut sont données sous forme :
-
-#ifndef NOUVELLE_OPTION
-#define NOUVELLE_OPTION (quelque chose)
-#endif
-
- dans l'en-tête habituelle.
-
- Ajouter une option qui redéfinisse quelque chose dans un
- fichier d'en-tête du système (i.e., un fichier dans
- /usr/include/sys/) est presque toujours une erreur.
- opt_foo.h ne peut pas
- être inclus dans ces fichiers parce que cela dégraderait plus
- sérieusement les en-têtes, et s'il n'est pas inclus, il peut
- alors y avoir des valeurs inconsistantes pour l'option là
- où il est inclus. Oui, il y a déjà des
- précédents, mais cela ne rend pas l'opération plus
- correcte.
-
-
-
-
-
diff --git a/fr_FR.ISO8859-1/books/handbook/policies/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/policies/chapter.sgml
deleted file mode 100644
index 17781d440a..0000000000
--- a/fr_FR.ISO8859-1/books/handbook/policies/chapter.sgml
+++ /dev/null
@@ -1,404 +0,0 @@
-
-
-
- Gestion de l'arborescence des sources
-
- Contribution de &a.phk;.
- &trans.a.haby;
-
- Ce document décrit différents principes et recommandations
- en vigueur pour la gestion de l'arborescence des sources de FreeBSD.
-
-
- <makevar>MAINTAINER</makevar> dans les
- <filename>Makefile</filename>s
-
- Juin 1996.
-
- Si un sous-ensemble particulier de la distribution de FreeBSD est
- maintenu par une personne ou un groupe de personne, ils peuvent le
- faire savoir à l'extérieur en ajoutant une
- ligne :
-
-
-MAINTAINER= email-addresses
-
-
- aux Makefiles correspondant à cette partie
- de l'arborescence.
-
- Cela signifie que :
-
- La personne détient et assume la responsabilité de ce
- code. Ce qui veut dire qu'il est responsable de la corrections des bogues
- et des réponses aux rapports d'anomalie se rapportant à ce
- code, et, dans le cas de logiciels d'origine extérieure, du suivi
- des nouvelles versions, selon les besoins.
-
- Les modifications dans les répertoires pour lesquels il existe
- un responsable de la maintenance devront être transmises à ce
- responsable pour qu'il les passe en revue. Il n'est admis
- d'intégrer de modifications sans passer par cette étape
- qu'aux seuls cas où le responsable ne répond pas dans un
- délai acceptable, et après plusieurs courriers
- électroniques. Il est cependant suggeré d'insister et de
- faire en sorte que les modifications soient revues par quelqu'un d'autre,
- si c'est possible.
-
- Il n'est bien sûr pas acceptable d'ajouter une personne ou un
- groupe de personnes comme responsable de la maintenance, s'ils ne sont pas
- d'accord pour assumer cette obligation. D'un autre côté, il
- n'est pas nécessaire que ce soit une personne ayant les droits
- d'écriture dans
- l'arborescence - “committer” - et
- ce peut sans problème être un groupe de personnes.
-
-
-
- Logiciels de provenance
- extérieure - “contribués”
-
- Contribution de &a.phk; et &a.obrien;.
-
- Juin 1996.
-
- Certaines parties de la distribution de FreeBSD consistent en
- logiciels qui sont activement maintenus extérieurement au projet
- FreeBSD. Pour des raisons historiques, on appelle cela des logiciels
- contribués. Perl, gcc et patch en sont des
- exemples.
-
- Ces deux dernières années, nous avons employé
- différentes méthodes pour gérer ce type de logiciels, elles ont toutes leurs avantages et leurs inconvénients. Aucune ne
- s'est avérée incontestablement meilleure.
-
- De ce fait, après discussion, une de ces méthode a
- été retenue comme méthode “officielle” et
- devra être utilisée pour les prochaines adjonctions de
- logiciels de ce type. De plus, il est fortement suggéré que
- les logiciels déjà intégrés convergent avec le
- temps vers cette méthode, parce qu'elle présente des
- avantages significatifs sur l'ancienne méthode, dont la
- possibilité pour chacun d'obtenir facilement des
- diffs avec les versions “officielles” du
- source (même sans accès cvs). Cela rendra beaucoup plus
- facile la communication en retour des modifications aux
- développeurs d'origine des logiciels.
-
- Au final, néanmoins, tout dépend des personnes qui ont
- en charge la maintenance. Si ce modèle est particulièrement
- mal adapté au paquetage concerné, il peut y avoir des
- exceptions à ces règles, à condition expresse
- d'approbation par l'équipe de base et de consensus
- général des autres développeurs, la
- maintenabilité ultérieure du paquetage étant le
- principal critère de décision.
-
-
- Du fait de limitations malheureuses de conception du format des
- fichiers RCS et de l'utilisation par CVS des branches d'origine, les
- modifications mineures, triviales et/ou cosmétiques sont
- fortement découragées sur les
- fichiers qui sont toujours gérés sur la branche
- d'origine. Les fichiers de “localisation” sont explicitement
- inclus ici dans la catégorie “cosmétique” et
- ne doivent pas avoir de numéros de révision
- 1.1.x.x. La modification d'un seul caractère
- peut congestionner de façon relativement dramatique l'ensemble
- des archives.
-
-
- Nous utiliserons le langage de programmation
- Tcl pour illustrer la façon dont ce
- modèle s'applique :
-
- src/contrib/tcl contient le source tel qu'il est
- distribué par les gens qui maintiennent ce paquetage. Les parties
- qui ne s'appliquent pas du tout à FreeBSD peuvent être
- supprimées. Dans le cas de Tcl, les sous-répertoires
- mac, win et
- compat ont été éliminés
- avant l'importation.
-
- src/lib/libtcl ne contient qu'un
- Makefile de “style bmake” qui utilise les
- règles standard de bsd.lib.mk pour
- générer la bibliothèque et installer la
- documentation.
-
- src/usr.bin/tclsh ne contient qu'un
- Makefile de “style bmake” qui
- génère et installe le programme
- tclsh et les pages de manuel correspondantes en
- utilisant les règles standard de
- bsd.prog.mk.
-
- src/tools/tools/tcl_bmake contient une paire de
- procédures qui peuvent être utiles quand il faut mettre
- à jour le logiciel Tcl. Elles ne font pas partie du logiciel
- compilé et installé.
-
- L'important ici est que le répertoire
- src/contrib/tcl est créé en respectant
- les règles suivantes : il est supposé contenir les
- sources tels que distribués (sur une branche CVS d'origine ad hoc
- et sans extensions RCS des mots-clés) avec aussi peu de
- modifications spécifiques à FreeBSD que possible. L'outil
- d'“importation facile” sur freefall
- aidera à importer le logiciel, mais, au moindre doute, il est
- impératif de se renseigner auparavant et de ne pas aller à
- l'aveuglette en espérant que “cela marchera”. CVS ne
- pardonne pas les erreurs d'importation et il n'est pas trivial de
- récupérer d'erreurs majeures.
-
- Du fait des limitations conceptuelles déjà
- mentionnées des branches d'origine de CVS, les correctifs
- “officiels” du distributeur doivent être
- appliqués aux sources d'origine et le résultat
- réimporté dans la branche principale. Ces correctifs
- officiels ne doivent jamais être appliqués aux versions
- extraites pour FreeBSD et “soumis” ensuite, parce que cela
- détruit la cohérence de la branche d'origine et rend
- l'importation des versions ultérieures assez difficile, parce qu'il
- y aura des conflits.
-
- Comme de nombreux paquetages contiennent des fichiers
- dédiés à la compatibilité avec d'autres
- architectures et environnements que FreeBSD, il est admissible de
- supprimer les parties de la distribution qui ne concernent pas FreeBSD
- pour gagner de la place. Les fichiers qui contiennent les notices de
- copyright et des informations du type
- “notes de version” qui s'appliquent aux autres fichiers ne
- doivent pas être supprimés.
-
- Si cela s'avère plus facile, les Makefiles
- bmake de l'arborescence de la distribution peuvent
- être générés avec un utilitaire, ce qui peut
- le cas échéant faciliter les montées de version. Si
- tel est le cas, veillez à administrer ces utilitaires (si besoin
- est) dans le répertoire src/tools en
- même temps que le logiciel lui-même, de sorte qu'ils soient
- disponibles pour les personnes qui assureront par la suite la
- maintenance.
-
- Dans le répertoire src/contrib/tcl, il
- faut ajouter un fichier appelé FREEBSD-upgrade qui mentionne des choses telles que :
-
-
-
- Quels fichiers ont été laissés de
- côté,
-
-
-
- Où a été obtenue la distribution originale
- et/ou quel est le site principal officiel,
-
-
-
- Où réadresser les correctifs à l'auteur
- original,
-
-
-
- Eventuellement un résumé des modifications
- apportées propres à FreeBSD.
-
-
-
- Cependant, n'importez pas FREEBSD-upgrade en
- même temps que le source du logiciel. Vous devriez plutôt
- effectuer un cvs add FREEBSD-upgrade ; cvs ci
- après le premier import. Voici par exemple
- ce que cela donne pour src/contrib/cpio
- Traduction :
-
-
-Ce répertoire contient les sources d'origine non modifiés sur la
-branche “d'origine”. N'essayez en aucun cas de mettre à jour
-les fichiers de ce répertoire via des correctifs et un “commit”
-cvs. Les nouvelles versions ou les versions officiellement
-rectifiées doivent être importées. N'oubliez pas d'importer
-avec l'option “-ko” pour ne pas écraser les IDentifiants
-RCS d'origine.
-
-A l'importation de GNU cpio 2.4.2, les fichiers suivants ont été
-éliminés :
-
- INSTALL cpio.info mkdir.c
- Makefile.in cpio.texi mkinstalldirs
-
-Pour passer à une nouvelle version de cpio, quand elle sera disponible :
- 1. Décompactez la nouvelle version dans un sous-répertoire vide
- [Ne modifiez en AUCUN cas les fichiers.]
-
- 2. Supprimez les fichiers listés ci-dessus et tous autres fichiers
- qui ne s'appliquent pas à FreeBSD.
-
- 3. Utilisez la commande :
- cvs import -ko -m 'Virgin import of GNU cpio v<version>' \
- src/contrib/cpio GNU cpio_<version>
-
- Voici par example comment j'ai importé la version 2.4.2 de cpio :
- cvs import -ko -m 'Virgin import of GNU v2.4.2' \
- src/contrib/cpio GNU cpio_2_4_2
-
- 4. Suivez les instructions affichées à l'étape 3 pour résoudre les
- conflits entre les modifications locales pour FreeBSD et la
- nouvelle version.
-
-Ne déviez en aucun cas de cette procédure.
-
-Pour appliquer les modifications locales à cpio, “patchez”
-simplement et soumettez sur la branche principale (aka HEAD).
-N'appliquez jamais les modifications locales à la branche GNU.
-
-Toutes les modifications locales doivent être soumises à
-“cpio@gnu.ai.mit.edu” pour inclusion dans la prochaine
-version originale.
-
-obrien@freebsd.org - 30 Mars 1997
- :
-
-
-This directory contains virgin sources of the original distribution files
-on a "vendor" branch. Do not, under any circumstances, attempt to upgrade
-the files in this directory via patches and a cvs commit. New versions or
-official-patch versions must be imported. Please remember to import with
-"-ko" to prevent CVS from corrupting any vendor RCS Ids.
-
-For the import of GNU cpio 2.4.2, the following files were removed:
-
-INSTALL cpio.info mkdir.c
-Makefile.in cpio.texi mkinstalldirs
-
-To upgrade to a newer version of cpio, when it is available:
- 1. Unpack the new version into an empty directory.
- [Do not make ANY changes to the files.]
-
- 2. Remove the files listed above and any others that don't apply to
- FreeBSD.
-
- 3. Use the command:
- cvs import -ko -m 'Virgin import of GNU cpio v<version>' \
- src/contrib/cpio GNU cpio_<version>
-
- For example, to do the import of version 2.4.2, I typed:
- cvs import -ko -m 'Virgin import of GNU v2.4.2' \
- src/contrib/cpio GNU cpio_2_4_2
-
- 4. Follow the instructions printed out in step 3 to resolve any
- conflicts between local FreeBSD changes and the newer version.
-
-Do not, under any circumstances, deviate from this procedure.
-
-To make local changes to cpio, simply patch and commit to the main
-branch (aka HEAD). Never make local changes on the GNU branch.
-
-All local changes should be submitted to "cpio@gnu.ai.mit.edu" for
-inclusion in the next vendor release.
-
-obrien@freebsd.org - 30 March 1997
-
-
-
-
- Bibliothèques partagées
-
- Contribution de &a.asami;, &a.peter;, and &a.obrien; 9
- Décembre 1996.
-
- Si vous ajoutez à des logiciels portés ou d'autres
- logiciels, le support des bibliothèques partagées qu'ils
- n'ont pas encore, les numéros de version des bibliothèques
- doivent suivre les règles ci-dessous. De façon
- générale, ces numéros n'ont pas de rapport avec les
- numéros de version du logiciel.
-
- Les trois principes de génération des
- bibliothèques partagées sont :
-
-
-
- Commencez à 1.0,
-
-
-
- Si la modification est rétro-compatible, augmentez le
- numéro de version mineure,
-
-
-
- Si la modification est incompatible avec les versions
- antérieures, augmentez le numéro de version
- majeure.
-
-
-
- Par exemple, l'ajout de fonctions et les corrections de bogues
- résultent en une incrémentation du numéro de version
- mineure, alors que la suppression de fonctions ou la modification de
- syntaxes d'appel de fonctions imposent un changement de numéro de
- version majeure.
-
- Tenez-vous en à des numéros de version de la forme
- majeure.mineure
- (x.y). Notre
- éditeur de liens dynamiques ne gère pas très bien
- les numéros de version de la forme
- x.y.z.
- Tout numéro de version après le
- y (i.e., le troisième chiffre) est
- totalement ignoré lors de la comparaison des numéros de
- version des bibliothèques partagées pour décider
- avec quelle bibliothèque effectuer le lien. Si deux
- bibliothèques partagées diffèrent d'une
- “micro” révision, ld.so fera le lien
- avec la plus élevée. I.e. : si vous éditez les liens
- avec libfoo.so.3.3.3, l'éditeur de liens
- n'enregistre que 3.3 dans les en-têtes, et fera
- le lien avec n'importe quoi qui commence par
- libfoo.so.3.(quelque chose >=
- 3).(le numéro le plus
- élevé disponible).
-
-
- ld.so utilisera toujours la révision
- “mineure” la plus élevée. I.e. : il
- choisira libc.so.2.2 plutôt que
- libc.so.2.0, même si le programme a
- été initialement lié avec
- libc.so.2.0.
-
-
- Pour les bibliothèques autres que celles des logiciels
- portés, c'est aussi notre politique de ne changer de numéro
- de version de bibliothèque partagée qu'une seule fois par
- version de FreeBSD. Si vous modifiez une bibliothèque
- système de telle sorte que cela réclame une
- incrémentation du numéro de version, consultez l'historique
- des soumissions du Makefile. C'est la personne qui
- soumet qui doit s'assurer que le numéro de version de la
- bibliothèque partagée est bien incrémenté
- à la première modification et que les modifications
- suivantes n'y touchent plus.
-
-
-
-
-
diff --git a/fr_FR.ISO8859-1/books/handbook/quotas/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/quotas/chapter.sgml
deleted file mode 100755
index 4ace312374..0000000000
--- a/fr_FR.ISO8859-1/books/handbook/quotas/chapter.sgml
+++ /dev/null
@@ -1,284 +0,0 @@
-
-
-
- Quotas d'utilisation des disques
-
- Contribution de &a.mpp;.26 Février
- 1996
- &trans.a.haby;
-
- Les quotas sont une option du système d'exploitation qui vous
- permet de limiter la quantité d'espace disque et/ou le nombre
- de fichiers auxquels ont droit un utilisateur ou tous les
- utilisateurs du même groupe, sur un système de fichiers donné.
- On les utilise la plupart du temps sur les systèmes en temps
- partagé sur lequel il est souhaitable de limiter la quantité de
- ressources allouée à un utilisateur ou à un groupe. Cela évite
- qu'un seul utilisateur consomme tout l'espace disque.
-
-
-
- Configurer votre système pour pouvoir utiliser les
- quotas d'utilisation des disques
-
- Avant d'essayer de mettre en place des quotas disque, il faut
- vous assurez que votre noyau est configuré pour cela. Pour ce faire,
- vous devez ajouter la ligne suivante au fichier de configuration de
- votre noyau:
-
-
-options QUOTA
-
-
- Cette option n'est pas activée par défaut dans le fichier noyau
- GENERIC de base, vous devez donc configurer,
- compiler et installer un noyau sur-mesure pour utiliser les quotas
- disque. Reportez-vous s'il vous plaît au chapitre
- Configurer le noyau de FreeBSD
- pour plus d'informations sur la configuration du noyau.
-
- Vous devrez ensuite mettre en service les quotas dans votre
- fichier /etc/sysconfig. Pour cela, remplacez
- la ligne:
-
-
-quotas=NO
- par:
-
-
-quotas=YES
-
-
- Si vous utilisez FreeBSD 2.2.2 ou ultérieur, ce fichier
- de configuration s'appelle /etc/rc.conf et le
- nom de la variable a été modifié en:
-
-
-check_quotas=YES
-
-
- Vous devez enfin éditer le fichier
- /etc/fstab pour mettre en service les quotas
- système de fichiers par système de fichiers. C'est là que vous
- dites si vous voulez des quotas d'utilisation des disques par
- utilisateur, par groupe ou les deux, pour chaque système de
- fichiers.
-
- Pour mettre en service des quotas par utilisateur, ajoutez
- l'option userquota à la zone d'options de
- l'entrée de /etc/fstab pour le système de
- fichiers sur lequel vous voulez des quotas. Par exemple:
-
-
-/dev/sd1s2g /home ufs rw,userquota 1 2
-
-
- De même, pour définir des quotas par groupe, utilisez l'option
- groupquota au lieu du mot-clé
- userquota. Pour avoir à la fois des quotas par
- utilisateur et par groupe, modifiez cette entrée de la façon
- suivante:
-
-
-/dev/sd1s2g /home ufs rw,userquota,groupquota 1 2
-
-
- Par défaut, les fichiers où sont définis les quotas se trouvent
- dans le répertoire racine du système de fichiers et s'appellent
- quota.user et
- quota.group, pour les quotas par utilisateur
- et, respectivement, par groupe. Consultez
- man fstab pour plus d'informations. Bien que les
- pages de manuel disent que vous pouvez mettre ces fichiers ailleurs,
- ce n'est pas recommandé parce qu'il semble que les divers utilitaires
- qui gèrent les quotas ne prennent pas tous cela correctement en
- compte.
-
- Vous devez maintenant redémarrer votre système avec le nouveau
- noyau. La procédure /etc/rc exécutera
- automatiquement les commandes nécessaires à la création des fichiers
- de quotas initiaux pour tous ceux que vous avez instaurés dans
- /etc/fstab, vous n'avez donc pas besoin de
- créer à la main des fichiers de quotas vides.
-
- Vous ne devriez normalement pas avoir à exécuter les commandes
- quotacheck, quotaon,
- ou quotaoff. Vous pouvez cependant lire les pages
- de manuel qui s'y rapportent, simplement pour savoir ce qu'elles
- font.
-
-
-
-
- Définir les quotas
-
- Maintenant que votre système est configuré pour mettre en place
- des quotas, vérifiez que cela marche bien. Cela ce fait facilement
- en exécutant:
-
-
- &prompt.root; quota -v
-
-
- Vous devriez obtenir une ligne de résumé d'utilisation du
- disque avec les quotas actuellement définis pour chaque système de
- fichiers sur lesquels il y a des quotas.
-
- Vous pouvez maintenant définir ces quotas avec la commande
- edquota.
-
- Il y a différentes option pour instaurer les quotas d'espace
- disque alloués à un utilisateur ou à un groupe et le nombre de
- fichiers qu'ils ont le droit de créer. Il peuvent être basés sur
- l'espace disque (quotas en nombre de blocs) ou le nombre de fichiers
- (quotas en nombre d'entrées dans le
- répertoire - “inode”) ou les deux. Ces options
- peuvent encore être subdivisées en deux catégories: limitations
- strictes ou souples.
-
- Les limites strictes ne peuvent jamais être dépassées. Dès qu'un
- utilisateur atteint sa limite stricte, il ne peut plus rien allouer
- sur le système de fichiers en question. Si par exemple, il n'a
- droit qu'à 500 blocs sur un système de fichiers et en utilise déjà
- 490, il ne peut plus en allouer que 10. S'il voulait en allouer 11,
- il n'y arriverait pas.
-
- Les limites souples peuvent elles être dépassées pour une période
- de temps restreinte. C'est ce que l'on appelle le délai de grâce, qui
- est d'une semaine par défaut. Si un utilisateur dépasse sa limite
- souple au delà du délai de grâce, cette limite devient stricte, et
- il ne peut plus rien allouer. Lorsqu'il redescend en dessous de
- la limite stricte, le délai de grâce lui est réaccordé.
-
- Voici un exemple de ce que vous pouvez voir en utilisant
- la commande edquota. Quand vous invoquez la
- commande edquota, vous vous retrouvez sous
- l'éditeur défini par la variable d'environnement
- EDITOR, ou sous vi
- si la variable d'environnement EDITOR n'est pas
- positionnée, ce qui vous permet d'éditer les quotas.
-
-
- &prompt.root; edquota -u test
-
-
-
-Quotas for user test:
-/usr: blocks in use: 65, limits (soft = 50, hard = 75)
- inodes in use: 7, limits (soft = 50, hard = 60)
-/usr/var: blocks in use: 0, limits (soft = 50, hard = 75)
- inodes in use: 0, limits (soft = 50, hard = 60)
-
-
- Il y aura normalement deux lignes pour chaque système de fichiers
- sur lequel il y a des quotas: une pour les quotas de blocs, l'autre
- pour les quotas d'entrées de répertoire. Modifiez simplement les
- valeurs que vous voulez mettre à jour. Par exemple, pour augmenter
- la limite de blocs accordée à cet utilisateur de 50 pour la limite
- souple et 75 pour la limite stricte à 500 pour la limite souple et
- 600 pour la limite stricte, modifiez:
-
-
-/usr: blocks in use: 65, limits (soft = 50, hard = 75)
- en:
-
-
-/usr: blocks in use: 65, limits (soft = 500, hard = 600)
-
-
- Ces nouveaux quotas seront en service dès que vous quitterez
- l'éditeur.
-
- Il est parfois souhaitable de définir des quotas pour une plage
- d'UIDs (identifiants utilisateur). Cela peut être réalisé par
- l'option de la commande
- edquota. Définissez d'abord les quotas voulus pour
- un seul utilisateur, puis exécutez edquota -p
- utilisateur_prototype premier_uid-dernier_uid.
- Par exemple, si les quotas voulus sont ceux de l'utilisateur
- test, la commande qui suit applique les
- mêmes quotas aux “uids” de 10.000 à 19.999:
-
-
- &prompt.root; edquota -p test 10000-19999
-
-
- Cette possibilité de définir des quotas pour une plage
- d'“uids” a été ajoutée après la version 2.1. Si
- vous voulez en bénéficiez sur un système 2.1, vous devez
- récupérer un version plus récente de
- edquota.
-
- Voyez man edquota pour des informations plus
- détaillées.
-
-
-
-
- Consulter les quotas et l'utilisation des disques
-
- Vous pouvez utiliser l'une des commandes
- quota ou repquota pour
- consulter les quotas et l'utilisation des disques.
- La commande quota peut être employée pour
- connaître les quotas et l'utilisation des disques pour un
- utilisateur et un groupe. Seul le super-utilisateur peut
- consulter les quotas et l'usage des disques des autres
- utilisateurs ou d'un groupe auquel il n'appartient pas.
- La commande repquota permet d'avoir un
- résumé des quotas et de l'utilisation des disques pour les
- systèmes des fichiers sur lesquels il y a des quotas.
-
- Voici un exemple de résultat obtenu avec la commande
- quota -v pour un utilisateur pour lequel on
- a défini des quotas sur deux systèmes de fichiers.
-
-
-
-Disk quotas for user test (uid 1002):
- Filesystem blocks quota limit grace files quota limit grace
- /usr 65* 50 75 5days 7 50 60
- /usr/var 0 50 75 0 50 60
-
-
- Dans cet exemple, l'utilisateur occupe 15 blocs de plus que la
- limite de 50 blocs qui lui est allouée sur le système de fichiers
- /usr et dispose d'un délai de grâce de 5 jours.
- Remarquez l'astérisque * qui indique que la limite
- est dépassée.
-
- Les systèmes de fichiers sur lequel l'utilisateur n'occupe pas
- de place n'apparaissent normalement pas dans les sorties de la
- commande quota, même s'il a des quotas
- sur ces systèmes de fichiers. L'option elle
- les liste, comme /usr/var dans l'exemple
- ci-dessus.
-
-
-
-
- * Quotas avec NFS
-
- Cette section est encore en cours de rédaction.
-
-
-
-
diff --git a/fr_FR.ISO8859-1/books/handbook/staff/chapter.sgml b/fr_FR.ISO8859-1/books/handbook/staff/chapter.sgml
deleted file mode 100644
index 004cbebd61..0000000000
--- a/fr_FR.ISO8859-1/books/handbook/staff/chapter.sgml
+++ /dev/null
@@ -1,790 +0,0 @@
-
-
-
-
-
- L'équipe du projet FreeBSD
-
- Le projet FreeBSD est géré et mis en oeuvre par les
- groupes de personnes suivantes :
-
-
- L'équipe de base
- FreeBSD - <foreignphrase>Core Team</foreignphrase>
-
- L'équipe de base de FreeBSD constitue le “Comité
- de Direction” du projet, responsable de définir les objectifs
- et l'orientation du projet ainsi que de la gestion de
- sections spécifiques de l'ensemble
- du projet FreeBSD.
-
- (par ordre alphabétique de patronyme) :
-
-
-
- &a.asami;
-
-
-
- &a.jmb;
-
-
-
- &a.ache;
-
-
-
- &a.bde;
-
-
-
- &a.gibbs;
-
-
-
- &a.dg;
-
-
-
- &a.jkh;
-
-
-
- &a.phk;
-
-
-
- &a.rich;
-
-
-
- &a.gpalmer;
-
-
-
- &a.jdp;
-
-
-
- &a.sos;
-
-
-
- &a.peter;
-
-
-
- &a.wollman;
-
-
-
- &a.joerg;
-
-
-
-
-
- Les développeurs FreeBSD
-
- Ce sont ceux qui ont les droits d'écriture et effectuent le
- travail d'ingénierie sur l'arborescence des sources. Tous les
- membres de l'équipe de base sont aussi développeurs.
-
-
-
- &a.ugen;
-
-
-
- &a.mbarkah;
-
-
-
- &a.stb;
-
-
-
- &a.pb;
-
-
-
- &a.abial;
-
-
-
- &a.jb;
-
-
-
- &a.torstenb;
-
-
-
- &a.dburr;
-
-
-
- &a.charnier;
-
-
-
- &a.luoqi;
-
-
-
- &a.ejc;
-
-
-
- &a.kjc;
-
-
-
- &a.archie
-
-
-
- &a.cracauer;
-
-
-
- &a.adam;
-
-
-
- &a.dillon;
-
-
-
- &a.dufault;
-
-
-
- &a.uhclem;
-
-
-
- &a.tegge;
-
-
-
- &a.eivind;
-
-
-
- &a.julian;
-
-
-
- &a.rse;
-
-
-
- &a.se;
-
-
-
- &a.sef;
-
-
-
- &a.fenner;
-
-
-
- &a.jfieber;
-
-
-
- &a.jfitz;
-
-
-
- &a.scrappy;
-
-
-
- &a.lars;
-
-
-
- &a.dirk;
-
-
-
- &a.shige;
-
-
-
- &a.billf;
-
-
-
- &a.gallatin;
-
-
-
- &a.tg;
-
-
-
- &a.brandon;
-
-
-
- &a.graichen;
-
-
-
- &a.jgreco;
-
-
-
- &a.rgrimes;
-
-
-
- &a.jmg;
-
-
-
- &a.hanai;
-
-
-
- &a.thepish;
-
-
-
- &a.jhay;
-
-
-
- &a.helbig;
-
-
-
- &a.ghelmer;
-
-
-
- &a.erich;
-
-
-
- &a.nhibma;
-
-
-
- &a.flathill;
-
-
-
- &a.foxfair;
-
-
-
- &a.hosokawa;
-
-
-
- &a.hsu;
-
-
-
- &a.mph;
-
-
-
- &a.itojun;
-
-
-
- &a.mjacob;
-
-
-
- &a.gj;
-
-
-
- &a.ljo;
-
-
-
- &a.kato;
-
-
-
- &a.andreas;
-
-
-
- &a.motoyuki;
-
-
-
- &a.jkoshy;
-
-
-
- &a.kuriyama;
-
-
-
- &a.grog;
-
-
-
- &a.jlemon;
-
-
-
- &a.truckman;
-
-
-
- &a.imp;
-
-
-
- &a.smace;
-
-
-
- &a.mckay;
-
-
-
- &a.mckusick;
-
-
-
- &a.ken;
-
-
-
- &a.hm;
-
-
-
- &a.tedm;
-
-
-
- &a.amurai;
-
-
-
- &a.markm;
-
-
-
- &a.max;
-
-
-
- &a.alex;
-
-
-
- &a.newton;
-
-
-
- &a.rnordier;
-
-
-
- &a.davidn;
-
-
-
- &a.obrien;
-
-
-
- &a.danny;
-
-
-
- &a.ljo;
-
-
-
- &a.fsmp;
-
-
-
- &a.smpatel;
-
-
-
- &a.wpaul;
-
-
-
- &a.jmacd;
-
-
-
- &a.wes;
-
-
-
- &a.steve;
-
-
-
- &a.mpp;
-
-
-
- &a.dfr;
-
-
-
- &a.darrenr;
-
-
-
- &a.csgr;
-
-
-
- &a.martin;
-
-
-
- &a.paul;
-
-
-
- &a.roberto;
-
-
-
- &a.chuckr;
-
-
-
- &a.guido;
-
-
-
- &a.dima;
-
-
-
- &a.sada;
-
-
-
- &a.nsayer;
-
-
-
- &a.wosch;
-
-
-
- &a.jseger;
-
-
-
- &a.simokawa;
-
-
-
- &a.vanilla;
-
-
-
- &a.msmith;
-
-
-
- &a.des;
-
-
-
- &a.brian;
-
-
-
- &a.mks;
-
-
-
- &a.stark;
-
-
-
- &a.karl;
-
-
-
- &a.taoka;
-
-
-
- &a.dt;
-
-
-
- &a.cwt;
-
-
-
- &a.pst;
-
-
-
- &a.hoek;
-
-
-
- &a.nectar;
-
-
-
- &a.swallace;
-
-
-
- &a.dwhite;
-
-
-
- &a.nate;
-
-
-
- &a.yokota;
-
-
-
- &a.jmz;
-
-
-
-
-
- Le projet de documentation de FreeBSD
-
- Le Projet de
- documentation de FreeBSD est responsable d'une série de
- services, chacun étant géré par une personne et ses
- adjoints (le cas échéant) :
-
-
-
- Gestion du projet de documentation
-
-
- &a.nik;
-
-
-
-
- Webmestre
-
-
- &a.wosch;
-
-
-
-
- Rédacteur en chef des Manuel de référence
- & Foire Aux Questions
-
-
- &a.faq;
-
-
-
-
- Rédacteur en chef de la lettre d'information succinte de
- FreeBSD
-
-
- Chris Coleman chrisc@vmunix.com
-
-
-
-
- Rédacteur en chef commercial
-
-
- &a.mbarkah;
-
-
-
-
- Rédacteur en chef pour les modifications au site Web
-
-
- &a.mbarkah;
-
-
-
-
- Conversion de LinuxDoc à DocBook
-
-
- &a.nik;
-
-
-
-
-
-
- Qui est responsable de quoi
-
-
-
- Architecte principal
-
-
- &a.dg;
-
-
-
-
- Gestionnaire du
- projet de documentation
-
-
- &a.nik;
-
-
-
-
- Internationalisation
-
-
- &a.ache;
-
-
-
- Réseau
-
-
- &a.wollman;
-
-
-
-
- Postmaster
-
-
- &a.jmb;
-
-
-
-
- Coordination des versions
-
-
- &a.jkh;
-
-
-
-
- Relations publiques & avec les entreprises˛
-
-
- &a.jkh;
-
-
-
-
- Officier de
- sécurité
-
-
- &a.imp;
-
-
-
-
- Gestionnaires
- des archives CVS
-
-
- Principal : &a.peter;
-
- Assistant : &a.jdp;
-
- International (Crypto) : &a.markm;
-
-
-
-
- Gestionnaire du
- catalogue des logiciels portés
-
-
- &a.asami;
-
-
-
-
- Liaison avec XFree86 Project, Inc.
-
-
- &a.rich;
-
-
-
-
- Support des forums de
- discussion
-
-
- &a.joerg;
-
-
-
-
- Administrateur
- GNATS
-
-
- &a.steve;
-
-
-
-
- Webmestre
-
-
- &a.wosch;
-
-
-
-
-
-
-
-
diff --git a/fr_FR.ISO8859-1/books/handbook/todo.sgml b/fr_FR.ISO8859-1/books/handbook/todo.sgml
deleted file mode 100644
index e471e64082..0000000000
--- a/fr_FR.ISO8859-1/books/handbook/todo.sgml
+++ /dev/null
@@ -1,9 +0,0 @@
-
-
-*** A Traduire ***