Linux BootPrompt-Howto <author>Paul Gortmaker, Editor. <date>v1.01, 18 Août 1995 <abstract> Ce document est le BootPrompt-Howto, qui est un condensé de tous les paramètres de boot qui peuvent être transmis au noyau de <bf>Linux</bf> lors de la séquence de boot. Ceci inclut tous les paramètres concernant les périphériques. Un tour d'horizon des logiciels les plus répandus pour démarrer le noyau de <bf>Linux</bf> est aussi inclus. Cette version française a été réalisée par Laurent RENAUD. </abstract> <toc> <sect>Introduction<label id="main-intro"> Le noyau a une capacité limitée pour accepter des informations au moment du démarrage sous la forme d'une ligne de commande, semblable à une liste d'arguments que vous pouvez passer à un programme. En général, ceci est utilisé pour donner au noyau des informations concernant les paramètres du matériel que le noyau n'est pas capable de déterminer tout seul, ou pour se substituer/écraser les valeurs que le noyau pourrait détecter. Cependant, si vous avez juste copié une image du noyau directement sur une disquette, (c.a.d <tt> cp zImage /dev/fd0</tt>) alors vous n'avez aucune chance de pouvoir spécifier quelque argument que ce soit à ce noyau. C'est pourquoi beaucoup d'utilisateurs de <bf>Linux</bf> utilisent des logiciels comme <em/LILO/ ou <em/loadlin/ qui se chargent de transmettre ces arguments au noyau, et de le faire alors démarrer. Cette version couvre les distributions du noyau jusqu'à la v1.2.13 incluse. Des informations qui font partie des noyaux en développement jusqu'à la version 1.3.18 sont aussi documentées. Le BootPrompt-Howto est edité et mis à jour par : <quote> Paul Gortmaker, <tt/Paul.Gortmaker@anu.edu.au/ </quote> <sect1>Responsabilité et Copyright<label id="copyright"> Ce document <em/n'est pas/ l'évangile ! Bien que ce soit probablement la source d'information la plus à jour que vous puissiez trouver. Personne n'est responsable de ce qui peut arriver à votre matériel à part vous. Si votre matériel s'enflamme brusquement (ce qui est quasiment impossible ! ) je ne suis pas responsable. C'est à dire QUE L'AUTEUR N'EST PAS RESPONSABLE DES DOMMAGES QUI PEUVENT ETRE PRODUITS PAR DES ACTIONS RESULTANT D'INFORMATIONS CONTENUES DANS CE DOCUMENT. Ce document est soumis au Copyright (c) 1995 de Paul Gortmaker. La copie textuelle et la distribution de ce document est autorisée à condition de reproduire la notice du copyright ainsi que cette autorisation de copie. La copie et la distribution de versions modifiées de ce document est autorisée sous les conditions de la copie textuelle, à condition que la notice de copyright soit incluse exactement comme dans l'original, et que la version adaptée soit distribuée sous les termes d'une autorisation identique a celle-ci. La copie et la distribution de traductions de ce document dans une autre langue est autorisée, sous les conditions citées ci-dessus pour les versions modifiées. Si vous avez l'intention d'incorporer ce document au sein d'une publication, merci de me contacter, et je ferai un effort pour m'assurer que vous avez les informations les plus à jour disponibles. Par le passé, des versions périmées de HOWTO ont été publiées, ce qui a attristé les developpeurs qui ont été harcelés de questions auxquelles ils avaient déjà répondu dans des versions plus récentes. <sect1>Documentation Associée<label id="other_docs"> Les documentations les plus à jour seront toujours les sources du noyau. Pas si vite ! Ne soyez pas effrayés. Vous n'avez pas besoin de connaître la programmation pour lire les commentaires dans les fichiers source. Par exemple, si vous recherchez un argument qui peut être transmis au pilote AHA1542 SCSI, il vous suffit d'aller dans le répertoire <tt>linux/drivers/scsi</tt>, et de regarder dans le fichier <tt/aha1542.c/ -- et dans les cent premières lignes vous trouverez en anglais une description simple et complète des paramètres de démarrage que le pilote 1542 peut recevoir. Si vous avez trouvé quels sont les paramètres que vous avez l'intention d'utiliser, et que vous voulez savoir comment transmettre ces informations au noyau, alors regardez la documentation qui correspond au logiciel que vous utilisez pour démarrer le noyau (par exemple : LILO ou loadlin). <sect1>Le groupe de discussion Linux<label id="news"> Si vous avez des questions sur la transmission des paramètres au noyau, s'il vous plait, LISEZ D'ABORD ce document. Si ce document et les documents associés qui sont mentionnés ci-dessus ne répondent pas à votre (vos) question(s), alors vous pouvez essayer de la (les) poser dans le groupe de discussion <Bf>Linux</Bf> (fr.comp.os.linux pour la France). Les questions générales concernant la configuration de votre système peuvent être directement posées dans le groupe comp.os.linux.setup. Nous vous demandons <em/s'il vous plaît/ de respecter ces quelques recommandations, et de ne pas cross-poster vos demandes dans d'autres groupes. <sect1>Nouvelles Versions de ce Document<label id="new-doc"> Les nouvelles versions (en anglais) de ce document peuvent être recupérées par FTP anonyme sur sunsite.unc.edu, dans le répertoire /pub/Linux/docs/HOWTO/* et différents sites ftp miroir <Bf>Linux</Bf>. Ces documents en langue française se trouvent sur le site ftp.ibp.fr dans de répertoire <tt>/pub/linux/french/docs/HOWTO</tt>. Des mises à jour seront faites chaque fois que de nouvelles informations / pilotes seront disponibles. Si la copie que vous êtes en train de lire date de plus de trois mois, c'est soit qu'elle est périmée, soit que j'ai été paresseux et que je ne l'ai pas mise à jour. Ce document est produit en utilisant le système SGML spécialement concu pour le projet <Bf>Linux</Bf> Howto, et il existe différents formats de sortie disponibles : postscript, dvi, ascii, html, et bientôt TeXinfo. Je vous recommande de visualiser ce document en HTML (via un logiciel de navigation WWW ) ou dans le format PostScript/dvi. Tous deux contiennent les références croisées qui sont perdues dans les conversions en ASCII. Si vous voulez obtenir la copie officielle de sunsite, voici l'URL. <url url="http://sunsite.unc.edu/mdw/HOWTO/BootPrompt-HOWTO.html" name="BootPrompt-HOWTO"> Si des ajouts ou des modifications de faible importance ont été faites, vous pouvez voir la dernière copie du document de travail à cette URL. <url url="http://rsphy1.anu.edu.au/˜gpg109/BootPrompt-HOWTO.html" name="Working Copy"> <sect>Vue d'Ensemble des Paramètres de Démarrage<label id="oview"> Cette partie donne un certain nombre d'exemples de logiciels qui peuvent être utilisés pour transmettre les paramètres de démarrage au noyau. Elle donne aussi une idée de la façon dont les paramètres sont traités, quelles sont les limitations des paramètres de démarrage, et la façon dont ils sont répartis vers chaque périphérique pour lesquels ils ont été conçus. <sect1>LILO (LInux LOader)<label id="lilo"> Le programme LILO (LInux LOader) écrit par Werner Almesberger est le plus couramment utilisé. Il a la capacité de démarrer différents noyaux, et stocke les informations de configuration dans un fichier contenant exclusivement du texte. Beaucoup de distributions fournissent LILO comme <sq>boot-loader</sq> (chargeur de noyau) par défaut. LILO peut démarrer DOS, OS/2, <Bf>Linux</Bf>, FreeBSD, etc. sans aucun problème, et il est très souple. LILO est fourni avec une documentation excellente, et pour les paramètres de démarrage dont nous parlons ici, la commande <tt/append=/ de LILO est d'une très grande importance. <sect1>LoadLin<label id="loadlin"> L'autre chargeur de noyau couramment utilisé est `LoadLin' qui est un programme DOS qui est capable de lancer un noyau <Bf>Linux</Bf> à partir du prompt du dos (avec des paramètres de démarrage) en supposant que certaines ressources sont disponibles. Ceci est très bien pour les gens qui utilisent le DOS et qui veulent basculer sur <Bf>Linux</Bf> à partir du DOS. C'est aussi très pratique si vous possédez du matériel qui est dépendant du pilote fourni pour le DOS afin de mettre le matériel dans un état donné. Un exemple fréquent : les cartes son `SoundBlaster Compatible' qui requièrent un pilote DOS pour tripoter un ensemble de registres exotiques pour mettre la carte dans un mode compatible SoundBlaster. Démarrez le DOS avec le pilote requis, et maintenant chargez <Bf>Linux</Bf> à partir du prompt du DOS avec loadlin en esquivant la remise à zéro de la carte qui intervient si on redémarre complètement la machine. De cette façon, la carte est laissée dans le mode compatible SB et par conséquent est utilisable sous <Bf>Linux</Bf>. Il y a aussi d'autres programmes qui peuvent être utilisés pour démarrer <Bf>Linux</Bf>. Pour une liste complète, regardez sur votre miroir ftp <Bf>Linux</Bf> local, les programmes disponibles dans le répertoire <tt>system/Linux-boot/</tt>. <sect1>L'utilitaire ``rdev'' <label id="rdev"> Un certain nombre des paramètres de démarrage du noyau ont leurs valeurs par défaut stockées dans différents octets de l'image du noyau. Il existe un utilitaire baptisé <tt/rdev/ qui est installé sur la plupart des systèmes et qui sait où sont ces valeurs, et comment les changer. Il peut aussi modifier un certain nombre de choses qui ne possèdent pas de paramètre de démarrage équivalent, comme le mode vidéo utilisé par défaut. L'utilitaire rdev est couramment associé à swapdev, ramsize, vidmode et rootflags. Les cinq paramètres que rdev peut modifier sont : le périphérique de démarrage, le périphérique de swap, la taille du disque RAM, le mode vidéo par défaut, et l'autorisation de lecture-seule/lecture-écriture sur le périphérique racine. Des informations plus complètes sur <tt/rdev/ peuvent être obtenues en tapant <tt/rdev -h/ ou en lisant la page correspondante du manuel fourni. <sect1>Comment le noyau gère t-il les paramètres ? La plupart des paramètres de démarrage utilisent la syntaxe suivante : <code> nom[=valeur_1]&lsqb,valeur_2]...&lsqb,valeur_11&rsqb </code> où `nom' est un mot clé unique qui est utilisé pour reconnaître à quelle partie du noyau sont destinées les valeurs associées (si il y en a). Plusieurs paramètres de démarrage peuvent être transmis sous forme d'une liste d'éléments, comme celle situé ci-dessus, séparés par des espaces. Notez que la limite de 11 paramètres est réelle, c'est pourquoi le code ci-dessus ne comporte que 11 paramètres séparés par des virgules pour un mot clé. Toutefois, vous pouvez réutiliser le même mot clé avec 11 paramètres de plus dans des situations très complexes, en sachant que ceci est accepté par la fonction de configuration. La plupart sont pris en charge par <tt>linux/init/main.c</tt>. Tout d'abord, le noyau cherche à voir si le paramètre fait partie des paramètres spéciaux comme `root=', `ro', `rw', ou `debug'. La signification de ces paramètres spéciaux est décrite plus loin dans ce document. Il parcourt alors une liste de fonctions de configuration (contenues dans le tableau <tt/bootsetups/) pour voir si la chaîne paramètre spécifiée (comme par exemple `foo') a été associée à une fonction de configuration (`foo_setup()') pour un périphérique particulier ou une partie du noyau. Si vous passez au noyau la ligne <tt>foo=3,4,5,6</tt> alors, il cherchera dans le tableau <tt/bootsetups/ pour voir si `foo' y figure. S'il y est, alors il pourra appeler la fonction de configuration associée à `foo' (foo_setup()) et prendra en charge les paramètres 3, 4, 5 et 6 tels qu'ils sont donnés dans la ligne de commande adressée au noyau. <sect1>Positionnement des Variables d'Environnement. Quelque chose du type `foo=bar', qui n'est pas accepté comme une fonction de configuration telle qu'elle est décrite ci-dessus, est interprétée comme une variable d'environnement à positionner. Un exemple (inutile ?) serait d'utiliser `TERM=vt100' comme paramètre de démarrage. <sect1>Passer des paramètres à `init' Tous les paramètres restants qui ne sont pas pris par le noyau et qui ne sont pas considérés comme étant des variables d'environnement sont transmis au processus initial, qui est généralement le programme <tt/init/. Le paramètre le plus couramment passé au processus <tt/init/ est le mot <em/single/ qui demande à <tt/init/ de démarrer l'ordinateur en mode mono-utilisateur, et de ne pas lancer les <sq>daemons</sq> (démons) habituels. Regardez la page du manuel correspondant à la version de <tt/init/ installée sur votre système, afin de connaître les paramètres acceptés. <sect>Paramètres Généraux non spécifiques à un Périphérique<label id="general"> Voici des paramètres qui ne sont pas liés à des périphériques particuliers. Ils sont simplement liés à un certain nombre de paramètres internes au noyau. <sect1>Le Paramètre `no387' Certains coprocesseurs i387 ont des bogues qui apparaissent lorsqu'ils sont utilisés en mode protégé 32 bits. Par exemple, certaines puces ULSI-387 récentes, provoquent un blocage irréverssible lorsqu'elles font des calculs un virgule flottante. L'utilisation du paramètre de démarrage `no387' fait ignorer à <Bf>Linux</Bf> le coprocesseur mathématique s'il y en a un. Bien sûr, votre noyau doit alors obligatoirement être compilé avec l'option d'émulation du coprocesseur ! <sect1>Le Paramètre `no-hlt' La famille des processeurs i386 (et les suivantes) ont une instruction `htl' qui indique au processeur que rien ne va se produire jusqu'à ce qu'un périphérique externe (clavier, modem, disque, etc.) demande au processeur d'accomplir une tâche. Ceci permet au processeur de se mettre dans un mode `low-power' (économie d'énergie) dans lequel il reste à l'état de zombi jusqu'à ce qu'un périphérique externe le réveille (généralement via une interruption). Certaines puces i486DX-100 récentes ont un problème avec l'instruction `htl' qui est le suivant : elles ne peuvent pas retourner en mode opérationnel de façon fiable après que cette instruction a été utilisée. L'utilisation de l'instruction `no-hlt' indique à <Bf>Linux</Bf> de simplement exécuter une boucle infinie quand il n'y a rien d'autre à faire, et de <em/ne pas / arrêter votre processeur quand il n'y a aucune activitée. Ceci permet aux personnes qui utilisent ces puces défectueuses d'utiliser <Bf>Linux</Bf>, bien qu'ils doivent être informés du fait que le remplacement dans le cadre de la garantie est possible. <sect1>Le paramètre `root=' Ce paramètre indique au noyau quel périphérique doit être utilisé comme <sq>root filesystem</sq> (racine du système de fichier) pendant le démarrage. Par défaut, c'est le périphérique racine du système sur lequel le noyau a été construit. Par exemple, si le noyau en question a été construit sur un système qui utilise `/dev/hda1' comme partition racine, alors le périphérique racine par défaut sera `/dev/hda1'. Pour outrepasser cette valeur et sélectionner le second lecteur de disquette comme périphérique racine, il faut utiliser `root=/dev/fd1'. Les périphériques racine valides sont des partitions sur un des périphériques disques suivants : (1) /dev/hdaN à /dev/hddN, où N est la partition pour les disques `a à d' compatibles ST-506. (2) /dev/sdaN à /dev/sdeN, où N est la partition pour les disques `a à e' compatibles SCSI. (3) /dev/xdaN à /dev/xdbN, où N est la partition pour les disques `a à b' compatibles XT. (4) /dev/fdN, où N est le numéro du lecteur de disquette. La valeur N=0 correspond au disque DOS `A:', et N=1 correspond à `B:'. La plus maladroite et la moins compatible des spécifications des périphériques racine ci-dessus, qui est le format nombre majeur/nombre mineur est aussi acceptée (par exemple /dev/sda3 a pour <it>major</it> 8, et pour <it>minor</it> 3, vous pouvez donc utiliser <tt/root=0x803/ comme alternative). C'est un des paramètres de démarrage qui a sa valeur par défaut stockée dans l'image du noyau, et qui peut être aussi modifiée par l'utilitaire <tt/rdev/. <sect1>Le paramètre `ro' Quand le noyau démarre, il a besoin du système de fichier racine, pour énumérer les éléments de base de celui-ci. C'est le système de fichier racine qui est monté au démarrage. Cependant, si le système de fichier racine est monté avec un accès en écriture, vous ne pourrez pas contrôler de façon fiable l'intégrité du système de fichier, car il peut y avoir des fichiers en cours d'écriture. L'option `ro' indique au noyau de monter le système de fichier racine en lecture seule, de façon que les programmes de contrôle de cohérence du système de fichier (fsck) puissent être certain qu'il n'y a pas d'écritures en cours pendant la durée du test. Aucun programme ou processus ne peut écrire dans les fichiers situés sur le système de fichier en question jusqu'à ce qu'il ait été `remonté' avec un accès en lecture/écriture. C'est un des paramètres de démarrage qui a sa valeur par défaut stockée dans l'image du noyau, et qui peut être aussi modifiée par l'utilitaire <tt/rdev/. <sect1>Le paramètre `rw' Ceci est le contraire le plus parfait de ce qui précéde, c'est à dire que ce paramètre indique au noyau de monter le système de fichier racine en lecture/écriture. N'exécutez surtout pas un programme de type `fsck' sur un système de fichier monté en lecture/écriture. La même valeur stockée dans le fichier image mentionné ci-dessus est aussi accessible via <tt/rdev/ <sect1>Le paramètre `debug' Le noyau envoie des messages importants (et moins importants) à l'opérateur via la fonction <tt/printk()/. Si le message est considéré comme important, la fonction <tt/printk()/ envoie une copie sur la console active, mais le transmet aussi à la fonction <tt/klogd()/ qui l'archive sur le disque. La raison pour laquelle le message est envoyé à la console et archivé sur disque, est simple : dans certaines circonstances malheureuses (par exemple une défaillance du disque) le message ne serait pas écrit sur le disque et serait perdu. Le seuil à partir duquel un message est considéré comme important, ou ne l'est pas, est déterminé par la variable <tt/console_loglevel/. Par défaut, l'affichage sur la console est déclenché pour tout ce qui depasse le <tt/DEBUG/ (niveau 7). Ces niveaux sont définis dans le fichier include <tt/kernel.h/. Le fait de spécifier comme paramètre de démarrage <tt/debug/ forcera le niveau de suivi à 10, de façon que <em/tous/ les messages du noyau apparaissent sur la console. Le niveau de suivi de la console peut aussi être positionné pendant l'utilisation via une option du programme <tt/klogd()/. Consultez la page du manuel correspondant à la version installée sur votre système, pour voir comment utiliser ce programme. <sect1>Le paramètre `reserve=' Ceci est utilisé pour <em/protéger/ les zones des ports d'I/O des programmes de test. La syntaxe de la commande est la suivante : <tscreen> reserve=iobase,extent[,iobase,extent]... </tscreen> Sur certaines machines, il peut-être nécessaire d'empêcher les pilotes de périphériques de contrôler les périphériques à une certaine adresse (auto-test). Ceci peut-être nécessaire pour du matériel mal conçu qui peut provoquer un <em/bloquage/ au démarrage (comme par exemple certaines cartes réseaux ethernet), du matériel mal reconnu, du matériel dont l'état a été modifié par un test récent, ou encore si vous ne voulez pas que le noyau initialise certains matériels. Le paramètre de démarrage <tt/reserve/ s'attaque à ce problème en spécifiant une zone d'un port d'entrée/sortie qui n'a pas besoin d'être testée. Cette zone est <sq>réservée</sq> (verrouillée) dans la table d'enregistrement des ports du noyau comme si un périphérique avait déjà été trouvé dans cette zone. Notons que ce mécanisme n'est pas nécessaire sur la plupart des machines. Il est indispensable d'utiliser ce paramètre uniquement en cas de problème ou dans certains cas particuliers. Les ports d'entrée/sortie dans la zone spécifiée sont protégés contre les contrôles de périphériques. Ceci a été introduit pour être utilisé lorsqu'un pilote plante, avec la NE2000 par exemple, ou identifie de façon incorrecte un autre périphérique comme étant le sien. Un pilote de périphérique correct ne doit pas tester une zone réservée, à moins qu'un autre paramètre de démarrage lui demande explicitement de le faire. Ceci implique que le paramètre <tt/reserve/ doit être le plus souvent utilisé avec un autre paramètre de démarrage. Par conséquent si vous spécifiez une région <tt/reserve/ pour préserver un périphérique particulier, vous devrez en général aussi spécifier de façon explicite un test pour ce périphérique. La plupart des pilotes ignorent la table d'enregistrement des ports si on leur donne une adresse spécifique. Par exemple, la ligne de démarrage <code> reserve=0x300,32 blah=0x300 </code> laisse tous les pilotes de périphériques, excepté le pilote pour `blah', tester 0x300-0x31f. Comme d'habitude avec les paramètres de démarrage, il existe une limite à 11 paramètres, c'est pourquoi vous ne pouvez indiquer que 5 zones protégées par mot clé <tt/reserve/. Plusieurs ordres <tt/reserve/ peuvent être utilisés si vous avec une requête vraiment très complexe. <sect1>Le paramètre `ramdisk=' Ceci indique la taille en Kilo-Octets du disque virtuel (RAM disk) que vous pouvez éventuellement utiliser. Par exemple, si vous souhaitez avoir un système de fichier racine sur une disquette 1.44 Mo chargé sur le disque virtuel, vous devrez utiliser : <code> ramdisk=1440 </code> C'est un des paramètres de démarrage qui a sa valeur par défaut stockée dans l'image du noyau, et qui peut être aussi modifié par l'utilitaire <tt/rdev/. <sect1>Le paramètre `mem=' L'appel initial au BIOS défini dans la spécification des PC, et qui renvoie la taille de la mémoire installée, a été conçu pour être capable de donner des tailles mémoire jusqu'à 64 Mo (Hé oui, encore une manque de prévoyance, tout comme les disques de 1024 cylindres...Pfffff). <Bf>Linux</Bf> utilise cet appel au BIOS au démarrage pour déterminer quelle est la quantité de mémoire installée. Si vous avez plus de 64 Mo de mémoire vive installée, vous pouvez utiliser ce paramètre de démarrage pour indiquer à <Bf>Linux</Bf> quelle est la quantité de mémoire dont vous disposez. Voici une citation de Linus sur l'utilisation du paramètre `mem='. <sq>Le noyau acceptera tous les paramètres `mem=xx' que vous lui donnerez, et s'il s'aperçoit que vous lui avez menti, il plantera lamentablement tôt ou tard. Le paramètre indique la plus haute zone adressable, donc `mem=0x1000000' signifie que vous avez 16 Mo de mémoire, par exemple. Pour une machine ayant 96 Mo de mémoire, le paramètre serait `mem=0x6000000'.</sq> NOTE NOTE NOTE: certaines machines peuvent utiliser le sommet de la mémoire pour le cache du BIOS ou quelque chose d'autre, c'est pourquoi il se peut que vous n'ayez pas vraiment la totalité de ces 96 Mo comme mémoire adressable. Le contraire est aussi exact : certaines puces feront un plan de la mémoire physique couverte par la zone BIOS dans la zone située juste au dessus du sommet de la mémoire, donc le sommet de la mémoire peut être actuellement 96Mo + 384ko par exemple. Si vous indiquez à <Bf>Linux</Bf> qu'il a plus de mémoire qu'il doit en avoir actuellement, des choses plutôt désagréables vous arriveront : peut-être pas tout de suite, mais un jour sûrement.'' Notez que cet argument n'a pas besoin d'être en hexadécimal, et que les suffixes `k' et `M' (en majuscule ou minuscule, peu importe) peuvent être utilisés pour indiquer respectivement kilo-octets et Méga-octets (le `k' multiplie par 10 votre valeur et le `M' la multiplie par 20). La mise en garde exposée ci-dessus reste vraie en cela qu'une machine avec 96 Mo peut fonctionner avec <tt/mem=97920k/ mais échouer avec soit <tt/mem=98304k/ ou <tt/mem=96M/. <sect>Paramètres de démarrage pour les Périphériques SCSI Cette section contient une description des paramètres de démarrage qui sont utilisés pour passer des informations concernant les adaptateurs hôtes et les périphériques SCSI. Notations utilisées dans cette section : <tt/iobase/ -- Le premier port d'Entrée/Sortie que le serveur SCSI occupe. Ceux-ci sont donnés en notation hexadécimale, et sont généralement situés dans la fourchette <tt/0x200/ à <tt/0x3ff/. <tt/irq/ -- L'interruption matérielle pour laquelle la carte a été configurée. Les valeurs autorisées dépendront de la carte en question, mais seront généralement 5, 7, 9, 10, 11, 12, et 15. Les autres valeurs étant généralement utilisées pour les périphériques courants comme les disques durs IDE, les lecteurs de disquettes, les ports série, etc. <tt/scsi-id/ -- L'identifiant que la carte-serveur utilise pour s'identifier elle-même sur le bus SCSI. Un certain nombre de cartes serveur vous permettront de modifier cette valeur, alors que d'autres ont cette valeur stockée de façon définitive sur la carte. La valeur par défaut la plus courante est sept, mais les cartes Seagate et Future Domain TMC-950 par exemple utilisent la valeur six. <tt/parity/ -- Détermine si la carte serveur SCSI doit demander aux périphériques connectés de fournir une valeur de parité avec tous les échanges d'information. La valeur 1 indique que la détection de parité est activée, et la valeur 0 désactive le contrôle de parité. Encore une fois, toutes les cartes ne supportent pas la sélection du contrôle de parité par les paramètres de démarrage. <sect1>Nombre maximum de LUN contrôlés (`max_scsi_luns=') Chaque périphérique SCSI peut avoir un nombre de `sous-périphériques' qui le composent. L'exemple le plus courant est représenté par les nouveaux CD-ROM SCSI qui utilisent plus d'un disque à la fois grâce à un chargeur de CD. Chaque CD est adressable comme un `Logical Unit Number' (LUN = Numéro d'Unité Logique) de ce périphérique multiple. Mais la plupart des périphériques comme les disques durs, les lecteurs de bande et autres, sont des périphériques simples et on leur attribue le LUN zéro. Le problème survient avec les périphériques à un seul LUN qui ont un mauvais microprogramme. Certains périphériques SCSI mal conçus (anciens et malheureurement nouveaux aussi) ne supportent pas d'être testés pour des LUN différents de zéro. Ils répondent en se bloquant, et peuvent aussi verrouiller tout le bus SCSI en même temps. Les nouveaux noyaux ont une option de configuration qui vous permet d'indiquer le nombre maximum de LUN à tester. Par défaut, ils ne testent que le LUN zéro, pour éviter le problème décrit ci-dessus. Pour spécifier le nombre de LUN à tester au moment du démarrage, il suffit d'entrer le paramètre de démarrage `max_scsi_luns=n', où n est un nombre compris entre un et huit. Pour éviter les problèmes décrits précédemment, on peut utiliser n=1 pour éviter de perturber les périphériques défectueux. <sect1>Paramètres pour les Lecteurs de Bande SCSI (`st=') Certaines configurations de démarrage pour les lecteurs de bande SCSI peuvent être obtenues en utilisant ce qui suit : <code> st=buf_size[,write_threshold[,max_bufs]] </code> Les deux premiers nombres sont donnés en kilo-octets. La valeur par défaut du <tt/buf_size/ est 32 ko, et la taille maximum qui peut être donnée est la valeur ridicule de 16384 ko. La zone <tt/write_threshold/ est la valeur à laquelle le tampon est envoyé vers la bande, avec une valeur par défaut de 30ko. Le nombre maximum de tampons varie en fonction du nombre de lecteurs détectés, et a une valeur par défaut égale à deux. Voici un exemple d'utilisation : <code> st=32,30,2 </code> Des indications plus précises peuvent être trouvées dans le fichier <tt/README.st/ qui est dans le répertoire <tt/scsi/ de l'arborescence des sources du noyau. <sect1>Adaptec aha151x, aha152x, aic6260, aic6360, SB16-SCSI (`aha152x=') Les valeurs aha font référence à des cartes et les valeurs aic font référence aux puces SCSI actuelles de ce type de cartes, y compris la Soundblaster-16 SCSI. Le code de test de ces serveurs SCSI recherche s'il existe un BIOS installé, et s'il n'est pas présent, le test ne trouvera pas votre carte. Vous aurez alors à utiliser le paramètre de démarrage avec la syntaxe suivante : <code> aha152x=iobase[,irq[,scsi-id[,reconnect[,parity]]]] </code> Notez que si le pilote a été compilé avec l'option de recherche d'erreur activée, une sixième valeur peut être spécifiée pour fixer le niveau de recherche d'erreur. Tous les paramètres sont décrits au début de cette section, et la valeur <tt/reconnect/ permet au périphérique de se déconnecter/reconnecter si une valeur différente de zéro est utilisée. Voici un exemple d'utilisation : <code> aha152x=0x340,11,7,1 </code> Notez que les paramètres doivent être donnés dans l'ordre, ce qui signifie que si vous désirez spécifier une configuration de parité, vous devrez alors indiquer les valeurs de iobase, irq, scsi-id et reconnect aussi. <sect1>Adaptec aha154x (`aha1542=') Ce sont les gammes de cartes aha154x. Les différentes cartes aha1542 ont un contrôleur de disquette i82077 en interne, tandis que les cartes de la série aha1540 n'en ont pas. Ce sont des cartes à <sq>busmastering</sq>, (contrôle de bus) et elles ont des paramètres qui permettent d'indiquer le niveau ``d'équité'' qui est utilisé pour partager le bus avec les autres périphériques. Le paramètre de démarrage ressemble à ce qui suit. <code> aha1542=iobase[,buson,busoff[,dmaspeed]] </code> Les valeurs couramment utilisées pour <tt/iobase/ sont les suivantes : <tt/0x130, 0x134, 0x230, 0x234, 0x330, 0x334/. Des clones de cartes autorisent d'autres valeurs. Les valeurs <tt/buson, busoff/ indiquent le nombre de microsecondes pendant lesquelles la carte est prioritaire sur le bus ISA. Les valeurs par défaut sont 11 μs prioritaire, et 4 μs non prioritaire, de façon que d'autres cartes (comme une carte Ethernet ISA LANCE) aient une chance d'avoir accès au bus ISA. La valeur <tt/dmaspeed/ fait référence à la vitesse (en Mo/s) à laquelle s'effectue le transfert DMA (Direct Memory Access, Mémoire à Accès Direct). La valeur par défaut est 5 Mo/s. Les nouvelles versions de ces cartes vous permettent de sélectionner cette valeur de façon logicielle alors que les anciennes cartes utilisait des cavaliers. Vous pouvez utiliser des valeurs allant jusqu'à 10 Mo/s en supposant que votre carte mère soit capable de les supporter. Expérimentez prudemment si vous utilisez des valeurs supérieures à 5 Mo/s. <sect1>Adaptec aha274x, aha284x, aic7xxx (`aic7xxx=') Ces cartes peuvent recevoir un paramètre selon la syntaxe suivante : <code> aic7xxx=extended,no_reset </code> La valeur de <tt/extended/, si elle est différente de zéro, indique que la traduction étendue pour les disques de grande capacité est activée. La valeur <tt/no_reset/, si elle est différente de zéro, indique au pilote de ne pas réinitialiser le bus SCSI lorsqu'il configure la carte-serveur au démarrage. <sect1>Les hôte SCSI BusLogic (`buslogic=') Pour l'instant, les pilotes buslogic n'acceptent qu'un seul paramètre, qui est l'adresse d'entrée/sortie. Elle doit être l'une des valeurs suivantes : <tt/0x130, 0x134, 0x230, 0x234, 0x330, 0x334/. <sect1>Future Domain TMC-8xx, TMC-950 (`tmc8xx=') Le code de test pour ces hôtes SCSI recherche un BIOS installé, et s'il n'en détecte aucun, le test ne trouvera pas votre carte. Ou si la signature de votre BIOS n'est pas reconnue, elle ne sera pas trouvée non plus. Dans ce cas, vous aurez à utiliser un paramètre de démarrage de la forme : <code> tmc8xx=mem_base,irq </code> La valeur <tt/mem_base/ est l'adresse dans le plan mémoire de la région d'entrée/sortie utilisée par la carte. C'est généralement une des valeurs suivantes : <tt/0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000/. <sect1>Pro Audio Spectrum (`pas16=') La PAS16 utilise une puce NC5380 SCSI, et les nouveaux modèles peuvent être configurés de façon logicielle. La syntaxe du paramètre est la suivante : <code> pas16=iobase,irq </code> La seule différence est que vous pouvez spécifier une valeur d'IRQ égale à 255, qui indique au pilote de travailler sans utiliser les interruptions, malheureusement au détriment des performances. La valeur de <tt/iobase/ est généralement <tt/0x388/. <sect1>Seagate ST-0x (`st0x=') Le code du programme de test de cet hôte SCSI recherche un BIOS installé, et s'il n'y en a aucun de présent, le test ne trouvera pas votre carte. Ou si la signature de votre BIOS n'est pas reconnue elle ne sera pas trouvée non plus. Dans ce cas, vous aurez à utiliser le paramètre suivant : <code> st0x=mem_base,irq </code> La valeur de <tt/mem_base/ est l'adresse dans le plan mémoire de la région d'entrée/sortie utilisée par la carte. En général, il s'agit d'une des valeurs suivantes : <tt/0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000/. <sect1>Trantor T128 (`t128=') Cette carte est aussi conçue autour de la puce NCR5380, et accepte les options suivantes : <code> t128=mem_base,irq </code> Les valeurs autorisées pour <tt/mem_base/ sont les suivantes : <tt/0xcc000, 0xc8000, 0xdc000, 0xd8000/. <sect1>Cartes n'acceptant pas les paramètres de démarrage Pour l'instant, les cartes SCSI suivantes n'utilisent aucun des paramètres de démarrage. Dans certains cas, vous pouvez <sq>bricoler</sq> les valeurs en éditant directement le pilote lui-même, si cela est nécessaire bien sûr. Always IN2000, Adaptec aha1740, EATA-DMA, EATA-PIO, Future Domain 16xx, NCR5380 (generic), NCR53c7xx à NCR53c8xx, Qlogic, Ultrastor (incl. u?4f), Western Digital wd7000, <sect>Disque Durs Cette section fait la liste de tous les paramètres de démarrage associés aux lecteurs de disques standards MFM/RLL, ST-506, XT, et IDE. Notez que les deux pilotes IDE et ST-506 HD acceptent l'option `hd='. <sect1>Paramètres des lecteurs de Disques/CD-ROM IDE Les pilotes IDE acceptent un certain nombre de paramètres, qui vont de la définition des caractéristiques du disque, à la correction des erreurs produites par les puces défectueuses. Les options spécifiques aux lecteurs sont introduites par les mots clé suivants : `hda=', `hdb=', `hdc=', ou `hdd='. Les options non spécifiques aux lecteurs sont introduites par le préfixe `hd='. Notez que l'utilisation d'un préfixe spécifique aux lecteurs pour une option non-spécifique marchera quand même, et que l'option sera appliquée comme désiré. Notez aussi que `hd=' peut-être utilisé pour faire référence au prochain disque non spécifié, dans la séquence (a, b, c, d). Dans le propos suivant, l'option `hd=' sera citée de façon concise. Consultez le fichier <tt/README.ide/ dans le répertoire <tt>linux/drivers/block</tt> si vous désirez de plus amples informations. <sect2>Les options `hd=cyls,heads,sects[,wpcom[,irq]]' Ces options sont utilisées pour décrire physiquement le disque. Seules les trois premières valeurs sont indispensables. Les valeurs de cylinder/head/sectors seront celles utilisées par <tt/fdisk/. La valeur de la précompensation d'écriture est ignorée pour les disques IDE. La valeur d'IRQ indiquée est celle utilisée par l'interface sur laquelle réside le disque, et ce n'est pas vraiment un paramètre spécifique au disque. <sect2>L'option `hd=serialize' La puce de la double interface IDE <sq>CMD-640</sq> était défectueuse dès sa construction. C'est pourquoi lorsque les disques de la seconde interface sont utilisés en même temps que ceux de la première interface, cela provoque une corruption des données. L'utilisation de cette option indique au pilote de s'assurer que les deux interfaces ne sont jamais utilisées en même temps. Si vous possédez uniquement deux lecteurs et que tous les deux sont reliés à la première interface, il est inutile de se servir de cette option. <sect2>L'option `hd=dtc2278' Cette option indique au pilote que vous avez une interface IDE DTC-2278D. Le pilote essaie alors d'effectuer des opérations spécifiques DTC pour activer la seconde interface et inhiber le mode de transfert rapide. <sect2>L'option `hd=noprobe' Si un lecteur particulier (par exemple un vieux lecteur IDE) a des problèmes liés aux tests, cette option peut-être utilisée pour désactiver le test. Voici un exemple d'utilisation : <code> hdb=noprobe hdb=1166,7,17 </code> Il désactive le test, mais précise aussi la description physique du disque, donc il sera reconnu comme périphérique bloc valide, et sera par conséquent utilisable. <sect2>L'option `hd=nowerr' Certains lecteurs semblent avoir le bit WRERR_STAT positionné en permanence. Ce paramètre active un mode de fonctionnement détourné pour ce périphérique défectueux. <sect2>L'option `hd=cdrom' Ceci indique au pilote IDE qu'il y a un CD-ROM compatible ATAPI connecté à la place habituelle d'un disque IDE. Dans la plupart des cas, le CD-ROM est identifié automatiquement, mais s'il ne l'est pas, ceci peut aider. <sect1>Options du pilote standart ST-506 (`hd=') Le pilote standart de disque accepte les mêmes paramètres que le pilote IDE. Notez cependant qu'il ne requiert que 3 valeurs (C/H/S) - Ni plus ni moins, et il vous ignorera -. De plus, il accepte uniquement le paramètre `hd=', c'est à dire que `hda=', `hdb=' et tout le reste ne sont pas autorisés ici. Le format est le suivant : <code> hd=cyls,heads,sects </code> Si deux disques sont installés, la ligne ci-dessus est répétée avec les caractéristiques techniques du second disque. <sect1>Options du pilote de disque XT (`xd=') Si vous êtez malchanceux au point d'utiliser une de ces vieilles cartes 8 bits qui transfère les données à la vitesse fulgurante de 125 ko/s c'est ici qu'est le scoop. Le code de test pour ces cartes recherche un BIOS installé et s'il n'en trouve pas, le test ne détectera pas votre carte. Ou encore, si la signature de votre BIOS n'est pas reconnue, le test ne trouvera pas votre carte non plus. Dans n'importe lequel de ces cas, vous devrez utiliser le paramètre suivant : <code> xd=type,irq,iobase,dma_chan </code> La valeur de <tt/type/ indique qui est le constructeur de la carte et peut prendre les valeurs suivantes : 0=generic; 1=DTC; 2,3,4=Western Digital, 5,6,7=Seagate; 8=OMTI. La seule différence entre les différents types pour un même constructeur est la chaîne BIOS utilisée pour la détection, et qui n'est pas utilisée si le type est spécifié. La fonction <tt/xd_setup()/ ne contrôle pas les valeurs, et supporte que vous saisissiez les 4 valeurs. Ne soyez pas déçu. Voici un exemple d'utilisation pour un contrôleur WD1002 avec un BIOS inactivé/supprimé, utilisant les paramètres `par défaut' du controleur XT : <code> xd=2,5,0x320,3 </code> <sect>CD-ROMs (Non-SCSI/ATAPI/IDE) Cette section fait l'inventaire de tous les paramètres de démarrage possibles pour les lecteurs de CD-ROM. Ceci n'inclut pas les CD-ROMs SCSI ou IDE/ATAPI. Consultez les sections appropriées pour ce type de CD-ROMs. <sect1>L'interface Aztech (`aztcd=') La syntaxe pour ce type de carte est : <code> aztcd=iobase[,magic_number] </code> Si vous positionnez le <tt/magic_number/ (nombre magique) à <tt/0x79/ alors le pilote essaiera puis laissera tomber dans le cas d'une microprogrammation inconnue. Toutes les autres valeurs seront ignorées. <sect1>L'interface Sony CDU-31A et CDU-33A (`cdu31a=') On rencontre cette interface CD-ROM sur certaines cartes son Pro Audio Spectrum, ainsi que sur les autres cartes d'interface fournies par Sony. La syntaxe est la suivante : <code> cdu31a=iobase,[irq[,is_pas_card]] </code> Le fait de spécifier une valeur d'IRQ égale à zéro indique au pilote que les interruptions logicielles ne sont pas supportées (comme sur certaines cartes PAS). Si votre carte supporte les interruptions, vous devrez les utiliser car elles abaissent la consommation de CPU par le pilote. Le `is_pas_card' peut-être saisi sous la forme suivante `PAS' si vous utilisez une carte Pro Audio Spectrum card, mais on peut aussi ne pas l'indiquer. <sect1>L'interface Sony CDU-535 (`sonycd535=') La syntaxe pour cette interface de CD-ROM est : <code> sonycd535=iobase[,irq] </code> La valeur zéro peut-être utilisée comme `bouche-trou' pour l'I/O base si l'on désire spécifier une valeur d'IRQ. <sect1>L'interface GoldStar (`gscd=') La syntaxe pour cette interface de CD-ROM est : <code> gscd=iobase </code> <sect1>L'interface standard Mitsumi (`mcd=') La syntaxe pour cette interface de CD-ROM est : <code> mcd=iobase,[irq[,wait_value]] </code> La valeur <tt/wait_value/ est utilisée comme une valeur interne de dépassement de temps pour les gens qui ont des problèmes avec leur disques, et peut-être ou ne pas être implémentée en fonctions d'une instruction <tt/DEFINE/ lors de la compilation. <sect1>L'interface Mitsumi XA/MultiSession (`mcdx=') Pour l'instant, ce pilote `expérimental' possède une fonction de configuration mais aucun paramètre n'est encore implémentée (version 1.3.15). Le matériel est le même que ci-dessus, mais le pilote possède de nouvelles fonctionnalités. <sect1>L'interface Optics Storage (`optcd=') La syntaxe pour ce type de carte est : <code> optcd=iobase </code> <sect1>L'interface Phillips CM206 (`cm206=') La syntaxe pour ce type de carte est : <code> cm206=[iobase][,irq] </code> La valeur de l'IRQ est comprise entre 3 et 11,et les adresses des ports d'entrée/sortie sont comprises entre <tt/0x300/ et <tt/0x370/, vous pouvez donc spécifier un ou deux nombres, dans n'importe quel ordre. Il accepte aussi `cm206=auto' pour désactiver l'autotest. <sect1>L'interface Sanyo (`sjcd=') La syntaxe pour ce type de carte est : <code> sjcd=iobase[,irq[,dma_channel]] </code> <sect1>L'interface SoundBlaster Pro (`sbpcd=') La syntaxe de ce type de carte est : <code> sbpcd=iobase,type </code> Où <tt/type/ prend une des valeurs suivantes (Attention : le respect des majuscules et des minuscules est important) : `SoundBlaster', `LaserMate', ou `SPEA'. L' I/O base est celle de l'interface de CD-ROM, et <em/non/ celle de la partie son de la carte. <sect>Autres Périphériques Matériels Tous les autres périphériques qui ne peuvent être classés dans une des catégories ci-dessus sont entassés ici. <sect1>Périphériques Ethernet (`ether=') Différents pilotes utilisent différents paramètres, mais ils partagent tous au moins une IRQ, une adresse d'entrée/sortie, et un nom. Dans sa forme la plus générique, cela ressemble à ça : <code> ether=irq,iobase[,param_1[,param_2,...param_8]]],name </code> Le premier argument non-numérique est pris comme nom. La valeur <tt/param_n/ (si elle est applicable) a généralement des significations différentes pour chaque carte/pilote. Les valeurs courantes de <tt/param_n/ sont utilisées pour indiquer des choses comme l'adresse de la mémoire partagée, la sélection d'interface, le canal DMA et ainsi de suite. L'utilisation la plus courante de ce paramètre est le forcement du test pour une seconde carte ethernet, alors que par défaut on en teste une seule. Ceci peut être accompli avec un simple ordre : <code> ether=0,0,eth1 </code> Notez que la valeur zéro pour l'IRQ et l'I/O base dans l'exemple ci-dessus indiquent au pilote de faire un autotest. Le Ethernet-HowTo décrit de façon exhaustive l'utilisation de plusieurs cartes simultanément, ainsi que la façon dont est utilisée la valeur <tt/param_n/ en fonction des spécificités de chaque carte/pilote. Les lecteurs concernés pourront faire référence à la section de ce document correspondant à leur carte pour une information plus précise. <sect1>Le pilote du Lecteur de Disquettes (`floppy=') Il existe de nombreuses options pour le pilote du lecteur de disquette, et qui sont listées dans le fichier <tt/README.fd/ dans le répertoire <tt>linux/drivers/block</tt>. Cette information est extraite directement du fichier. <sect2>floppy=mask,allowed_drive_mask Positionne le <sq>bitmask</sq> (masque binaire) des lecteurs autorisés à la valeur <tt/mask/. Par défaut, seules les unités 0 et 1 de chaque contrôleur de lecteur de disquette sont autorisées. Ceci est fait car certains matériels non-standards (cartes mères ASUS PCI) mettent la pagaille dans le clavier lorsque l'on accède aux unités 2 ou 3. Cette option est un peu obsolète en raison de l'option cmos. <sect2>floppy=all_drives Positionne le <sq>bitmask</sq> (masque binaire) des disques autorisés à tous les disques. Utilisez ceci si vous avez plus de deux lecteurs de disquette connectés à un contrôleur de lecteur de disquettes. <sect2>floppy=asus_pci Positionne le <sq>bitmask</sq> uniquement aux unités autorisées 0 et 1. (Par défaut) <sect2>floppy=daring Indique au pilote du lecteur de disquette que vous avez un contrôleur de lecteur de disquette qui se conduit bien. Ceci permet des opérations plus efficaces et plus discrètes, mais peut échouer sur certains contrôleurs. Ceci peut accélérer certaines opérations. <sect2>floppy=0,daring Indique au lecteur de disquette que votre contrôleur doit être utilisé avec précaution. <sect2>floppy=one_fdc Indique au lecteur de disquette que vous n'avez qu'un contrôleur de lecteur de disquette (Par défaut). <sect2>floppy=two_fdc <em/ou/ floppy=address,two_fdc Indique au lecteur de disquette que vous avez deux contrôleurs de lecteurs de disquette. Le second contrôleur est supposé être à l'adresse indiquée. Si l'adresse n'est pas donnée on suppose qu'elle est égale à 0x370. <sect2>floppy=thinkpad Indique au lecteur de disquette que vous avez un Thinkpad. Les Thinkpads utilisent une convention inversée pour la <sq>disk change line</sq> (ligne de changement de disque). <sect2>floppy=0,thinkpad Indique au lecteur de disquette que vous ne possédez pas un Thinkpad. <sect2>floppy=drive,type,cmos Positionne le type cmos du <tt/drive/ à <tt/type/. De plus, ce lecteur est autorisé dans le <sq>bitmask</sq> (masque binaire). C'est pratique si vous avez plus de deux lecteurs de disquette (seuls deux peuvent être décrits dans la cmos physique), ou si votre BIOS utilise un type de CMOS non-standard. Si l'on positionne le CMOS à 0 pour les deux premiers disques (par défaut) le pilote de lecteur de disquette ira lire la cmos physique. <sect2>floppy=unexpected_interrupts Imprime un message d'alerte lorsqu'une interruption inattendue est reçue (comportement par défaut). <sect2>floppy=no_unexpected_interrupts <em/or/ floppy=L40SX Ne pas imprimer de message lorsqu'une interruption inattendue est reçue. Ceci est nécessaire sur un IBM L40SX portable dans certains modes vidéo (il semble qu'il y ait une interaction entre la vidéo et les disquettes). Les interruptions inattendues affectent seulement les performances, et peuvent être ignorées sans crainte). <sect1>Le pilote de sons (`sound=') Le pilote de sons peut aussi recevoir des paramètres de démarrage qui écraseront les valeurs compilées dans le programme. Ceci n'est pas recommandé, et de plus c'est complexe. Ceci est décrit dans le fichier <tt/Readme.Linux/, dans le répertoire <tt>linux/drivers/sound</tt>. Il accepte de recevoir un paramètre de la forme : <code> sound=device1[,device2[,device3...[,device11]]] </code> Où chaque valeur de <tt/deviceN/ est de la forme <tt/0xTaaaId/, et les octets sont utilisés de la façon suivante : T - type de périphérique : 1=FM, 2=SB, 3=PAS, 4=GUS, 5=MPU401, 6=SB16, 7=SB16-MPU401 aaa - adresse d'entrée/sortie en hexa. I - ligne d'interruption en hexa (i.e 10=a, 11=b, ...) d - canal DMA. Comme vous pouvez le voir, ceci reste assez malpropre et vous ferez mieux de compiler vos propres valeurs comme c'est recommandé. Si l'on utilise un paramètre de démarrage `sound=0' on désactive entièrement le pilote de sons. <sect1>Le pilote de souris sur bus <sq>Bus Mouse</sq> (`bmouse=') Le pilote des souris sur bus accepte un seul paramètre, qui est la valeur de l'IRQ matérielle à utiliser. <sect>Conclusion Si vous avez trouvé des fautes de frappe manifestes, ou des informations périmées dans ce document, faites le moi savoir. Il est facile de laisser passer quelque chose. Merci, Paul Gortmaker, <tt/Paul.Gortmaker@anu.edu.au/ Merci de faire parvenir vos remarques sur la traduction de ce document à Laurent Renaud, <tt/100410.21@compuserve.com/ (<tt>http://ourworld.compuserve.com/homepages/LRENAUD/</tt>) </article>