<!--

    Ce document a été traduit par Laurent RENAUD.
    Traduction achevée le 21 Mars 1998. Bonne Lecture !


	Source SGML du BootPrompt-Howto
	===============================

	Maintenu par Paul Gortmaker.

	Date de Dernière Modification : 1er Février 1998

	(Ne pas oublier de mettre à jour les références à la version actuelle
	du noyau dans l'introduction et le résumé)


	Historique:

	1) Août 1995 - Il n'existe toujours pas de documentation recensant
	   les paramètres qui peuvent être passés au noyau pour les
	   utilisateurs qui en cherchent l'existance ou le mode d'emploi.
	   C'est pourquoi je m'y suis attaqué, ayant déjà l'expérience
	   de la doc linux-sgml avec le Ethernet-HowTo. (Bien sûr, la liste
	   la plus récente est le noyau lui même, mais il ne se prête pas
	   vraiment aux débutants.)

	2) Juillet 1996 - Mise à jour pour la version 2.0 du noyau, et ajout dans
	tout le document des choses que j'avais laissé de côté dans la première
	version, il y a presque 1 an (!). Copie des conditions GPL (elles y étaient
	déjà, telles que je les avaient trouvées dans le GNU Make Manuel, mais je
	n'avais pas dit explicitement GPL).

	3) Décembre 1996 - Quelques mises à jour mineures pour le noyau v2.0.27.	Ce devrait être bon pour un moment... (ha ! )

	4) Novembre 1997 - Ajout de quelques mises à jour pour la version 2.0.31	du noyau pour être en phase avec la nouvelle édition du livre LSL.

	5) Février 1998 - Quelques correction mineures (2.0.33).

A Faire :

	Passer au peigne fin les sources du 2.1 et ajouter de nouveaux paragraphes
	correspondant aux nouveaux pilotes de périphériques.

	Enlever toutes les occurences de <code> ... </code>

	Rendre conforme au guide de style de la LDP

-->

<!doctype linuxdoc system>

<article>

<title>The Linux BootPrompt-HOWTO
<author>Par Paul Gortmaker.
<date>v1.14, 1er Février 1998

<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. Une partie traitant de la façon
	dont le noyau trie les paramètres de démarrage ainsi qu'un tour d'horizon
	des logiciels les plus répandus pour démarrer le noyau de <bf>Linux</bf>	sont aussi inclues. <bf>Cette version française a été réalisée par</bf>
	<em> Laurent RENAUD</em><tt> (lrenaud@hol.fr).</tt> 
</abstract>

<toc>

<sect>Introduction<label id="main-intro">

<p>

	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.

	<em/NOTE IMPORTANTE POUR LES UTILISATEURS DE MODULES&nbsp;:/ Les
	paramètres de démarrage en général, ne s'appliquent qu'aux pilotes de
	matériel qui sont compilés directement dans le noyau.
	Ils n'ont <em/aucun effet/ sur les pilotes qui
	sont chargés en tant que modules. La plupart des distributions utilisent
	des modules. Si vous ne savez pas, regardez dans <tt/man depmod/ et
	<tt/man modprobe/ en suivant le contenu de <tt>/etc/conf.modules</tt>.

	Cette version couvre les distributions du noyau jusqu'à la v2.0.33 
	incluse. Des informations qui font partie des noyaux en développement 
	jusqu'à la version 2.1.84 sont aussi documentées.

	Le BootPrompt-Howto est edité et mis à jour par&nbsp;:
<quote>
	Paul Gortmaker, <tt/gpg109@rsphy1.anu.edu.au/
</quote>

	&lsqb;Notez que les paramètres de démarrage qui sont spécifiques aux 
	ports et périphériques non-i386 (ex&nbsp;: Atari/Amiga) ne sont actuellement
	pas documentés.&rsqb;


<sect1>Responsabilité et Copyright<label id="copyright"> 
<p>

	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-1998 de Paul Gortmaker.

	Ce document peut être copié en respectant les termes de la GNU General 
	Public Licence, version 2, ci-incluse en référence. Voir le fichier 
	<tt>linux/COPYING</tt> fourni avec le noyau Linux pour plus de détails.

	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
<p>

	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</tt> 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.

	Une autre bonne chose seront les fichiers de documentation livrés avec
	le noyau lui-même. Il y en a aujourd'hui pas mal, et la plupart d'entre
	eux peuvent-être trouvés dans le répertoire <tt>linux/Documentation</tt>	et tous ses sous répertoires. Le répertoire <tt>linux</tt> se trouve
	généralement dans <tt>/usr/src/</tt>. Parfois des fichiers
	<tt>README.foo</tt> peuvent se trouver dans le répertoire associé aux
	pilotes (c.a.d. <tt>linux/drivers/XXX/</tt>, où <tt>XXX</tt> sera
	<tt>scsi</tt>, <tt>char</tt>, ou <tt>net</tt>.

	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&nbsp;: LILO ou loadlin). Un bref survol est fourni ci-dessous, mais
	il ne remplace pas la documentation fournie avec le logiciel de démarrage.

<sect1>Le groupe de discussion Linux<label id="news"> 
<p>

	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).
	Bien sûr, il serait bon de lire les messages du groupe avant de poser
	aveuglément vos questions, il se peut que quelqu'un d'autre ait déjà posé
	la même question, ou peut-être est-ce une question fréquemment posée (FAQ).
	Un coup d'oeuil rapide à la FAQ linux avant de poster est une <em>bonne</em>
	idée. On pourra trouver les FAQ quelque part, dans un répertoire proche
	de celui où vous avez trouvé ce document.

	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"> 
<p>

	Les nouvelles versions (en anglais) de ce document peuvent être
	recupérées par FTP anonyme sur le site sunsite.unc.edu, dans le répertoire
	<tt>/pub/Linux/docs/HOWTO/</tt>. Notez que <em>SunSITE</em> est souvent
	surchargé, donc il vaudrait mieux aller chercher ce document sur un des
	sites ftp miroir de Linux.

	Ces documents en langue française se trouvent sur le site ftp.lip6.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 quelques mois, il serait bon de
	vérifier qu'il n'en existe pas une version plus récente.

	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&nbsp;: 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">


<sect>Vue d'Ensemble des Paramètres de Démarrage<label id="oview"> 
<p>

	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.

	Il est <em/important/ de noter que l'on <em/ne peut pas/ utiliser
	d'espaces dans un paramètre de démarrage, mais seulement entre des
	paramètres différents. Une liste de valeurs correspondant à un seul 
	paramètre doit utiliser des virgules comme séparateur entre les
	différentes valeurs, là aussi, sans aucun espace. Voir les exemples
	ci-dessous.

<code>
	ether=9,0x300,0xd0000,0xd4000,eth0  root=/dev/hda1	      *BON*
	ether = 9, 0x300, 0xd0000, 0xd4000, eth0  root = /dev/hda1    *MAUVAIS*
</code>


<sect1>LILO (LInux LOader)<label id="lilo"> 
<p>

	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.

	Une configuration classique est d'avoir LILO qui arrête le
	démarrage et affiche <tt/LILO:/ peu de temps après que vous ayez
	allumé votre ordinateur. Il attendra alors quelques instants en vue
	d'une eventuelle saisie de l'utilisateur, faute de quoi il lancera
	le système d'exploitation par défaut. Les étiquettes couramment
	utilisées dans les fichiers de configuration de LILO sont <tt/linux/
	, <tt/backup/ et <tt/msdos/. Si vous désirez entrer un paramètre de
	démarrage, vous le taperez ici, après avoir entré l'étiquette du système
	que vous voulez que LILO lance, comme indiqué dans l'exemple ci-dessous.

<code>
	LILO: linux root=/dev/hda1
</code>


	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 lorsque l'on
	veut ajouter un paramètre de démarrage de façon permanente dans le
	fichier de configuration de LILO. Vous ajoutez tout simplement quelque
	chose comme <tt/append = "foo=bar"/ dans le fichier
	<tt>/etc/lilo.conf</tt>. On peut l'ajouter soit en haut du fichier
	de configuration, afin qu'il s'applique à toutes les sections, ou
	dans une section correspondant à un système particulier en le mettant
	dans une section <tt/image=/.
	Voyez la documentation de LILO pour une description plus complète.


<sect1>LoadLin<label id="loadlin"> 
<p>

	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&nbsp;: les cartes son
	`SoundBlaster Compatible' qui requièrent un pilote DOS pour positioner
	un ensemble de registres propriètaires 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
	<tt>LOADLIN.EXE</tt> 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"> 
<p>

	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</tt> 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&nbsp;: le périphérique de démarrage, le périphérique de swap,
	les paramètres 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</tt> peuvent être obtenues
	en tapant <tt>rdev -h</tt> ou en lisant la page correspondante du manuel
	fourni (<tt>man rdev</tt>).

<sect1>Comment le noyau gère t-il les paramètres ?
<p>

	La plupart des paramètres de démarrage utilisent la syntaxe suivante&nbsp;:

<code>
        nom&lsqb;=valeur_1&rsqb;&lsqb,valeur_2&rsqb;...&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. Notez aussi que le noyau partage la liste
	en un maximum de 10 paramètres entiers, et une chaîne de caractères
	accompagnatrice, donc vous pouvez réellement fournir 11 entiers, dans
	la mesure ou vous assurez la conversion du 11ème paramètre, de chaîne
	en entier, dans le pilote lui même.

	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</tt>) pour voir si la chaîne paramètre
	spécifiée (comme par exemple `foo') a été associée à une fonction
	de configuration (<tt>foo_setup()</tt>) pour un périphérique particulier ou
	une partie du noyau. Si vous passez au noyau la ligne
	<tt>foo=3,4,5,6,bar</tt> alors, il cherchera dans le tableau
	<tt>bootsetups</tt> pour voir si `foo' y figure. S'il y est, alors il pourra
	appeler la fonction de configuration associée à `foo' (<tt>foo_setup()</tt>)
	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, et traitera aussi le
	paramètre de type chaîne <tt>bar</tt>.


<sect1>Positionnement des Variables d'Environnement.
<p>

	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 au programme `init'
<p>

	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</tt>. Le paramètre le plus
	couramment passé au processus <tt>init</tt> est le mot <em>single</em>
	qui demande à <tt>init</tt> 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</tt> 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">
<p>

	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, comme la gestion mémoire, celle du
	disque RAM, celle du système de fichiers racine, etc.


<sect1>Options du système de fichiers racine
<p>

	Les options suivantes déterminent toutes la façon dont le noyau
	sélectionne et manipule le système de fichiers racine.

<sect2>Le paramètre `root='
<p>

	Ce paramètre indique au noyau quel périphérique doit être utilisé
	comme <sq>root filesystem</sq> (racine du système de fichiers) 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 un des périphériques suivants&nbsp;:

	(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:'.

	(5) /dev/nfs, qui n'est pas vraiement un périphérique, mais plutôt un
	indicateur pour dire au noyau de rechercher le système de fichiers
	racine via le réseau.

	La plus maladroite et la moins compatible des spécifications
	des périphériques disque ci-dessus, qui est le format
	nombre majeur/nombre mineur est aussi acceptée (par exemple
	/dev/sda3 a pour major 8, et pour minor 3,
	vous pouvez donc utiliser <tt>root=0x803</tt> 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</tt>.

<sect2>Le paramètre `ro'
<p>

	Quand le noyau démarre, il a besoin du système de fichiers
	racine, pour énumérer les éléments de base de celui-ci.
	C'est le système de fichiers racine qui est monté au démarrage.
	Cependant, si le système de fichiers 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 fichiers, car il peut y avoir
	des fichiers en cours d'écriture.
	L'option `ro' indique au noyau de monter le système de fichiers
	racine  en lecture seule, de façon que les programmes de
	contrôle de cohérence du système de fichiers (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 fichiers 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</tt>.

<sect2>Le paramètre `rw'
<p>

	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 fichiers monté en
	lecture/écriture.

	La même valeur stockée dans le fichier image mentionné ci-dessus
	est aussi accessible via <tt>rdev</tt>


<sect1>Options liées à la gestion des disques virtuels (disques RAM)
<p>

	Les options suivantes correspondent à la façon dont le noyau gère
	le périphérique disque virtuel, qui est souvent utilisé comme zone
	d'amorçage durant la phase d'installation, ou pour des machines qui
	utilisent des pilotes modulaires qui doivent être installés pour
	accéder au système de fichiers racine.   

<sect2>Le paramètre `ramdisk_start='   
<p>

	Pour permettre à une image du noyau de loger sur une disquette,
	conjointement avec une image compressée du disque virtuel, la commande
	`ramdisk_start=&lt;offset&gt;' est ajoutée. Le noyau ne peut pas être
	inclus dans l'image compressée du système de fichiers du disque virtuel,
	car il doit être stocké à partir du bloc zéro de façon à ce que
	le BIOS puisse charger le secteur d'amorce (bootsector) et que le noyau
	puisse alors s'auto-lancer.

	Note&nbsp;: Si vous utilisez une image du disque virtuel non compressée,
	alors le noyau peut faire partie de l'image du système de fichiers qui
	est chargé sur le disque virtuel, et la disquette peut-être lancée avec
	LILO, ou les deux peuvent être distincts comme c'est fait pour les
	images compressées.

	Si vous utilisez deux disques boot/root (noyau sur le disque 1, image 
	u disque virtuel sur le disque 2) alors, le disque virtuel démarrera
	au bloc zéro, et un déplacement (offset) de zéro sera utilisé.
	Etant donné que c'est la valeur par défaut, vous n'aurez pas besoin
	actuellement d'utiliser cette commande.

<sect2>Le paramètre `load_ramdisk='
<p>

	Ce paramètre indique au noyau si il essaye de charger une image
	du disque virtuel ou pas. En spécifiant `load_ramdisk=1' on indiquera
	au noyau de charger une disquette dans le disque virtuel. La valeur
	par défaut est zéro, ce qui signifie que le noyau n'essaiera pas de
	charger un disque virtuel.

	Voyez le fichier <tt>linux/Documentation/ramdisk.txt</tt>
	pour une description complète des nouveaux paramètres de démarrage,
	et comment les utiliser. La façon dont ces paramètres peuvent être
	positionnés et stockés dans l'image du noyau via 'rdev' est aussi
	décrite.

<sect2>Le paramètre `prompt_ramdisk='
<p>

	Ce paramètre indique au noyau si il doit ou non vous demander d'insérer
	la disquette contenant l'image du disque virtuel. Dans une configuration
	à une seule disquette, l'image du disque virtuel est sur la même
	disquette que le noyau qui vient juste de se charger/démarrer, et donc
	un message d'invite est inutile. Dans ce cas, on peut utiliser
	`prompt_ramdisk=0'. Dans une configuration avec deux disquettes,
	vous devez avoir la possibilité de changer de disquette, et alors
	`prompt_ramdisk=1' peut-être utilisé. Etant donné que c'est la valeur
	par défaut, on n'a pas vraiment besoin de l'indiquer.

	Note Historique&nbsp;: Des gens sournois on l'habitude d'utiliser l'option
	de LILO `vga=ask' pour stopper temporairement le démarrage et avoir
	ainsi une chance de pouvoir passer de la disquette boot à la disquette
	root.

	Voyez le fichier <tt>linux/Documentation/ramdisk.txt</tt>
	pour une description complète des nouveaux paramètres de démarrage,
	et comment les utiliser. La façon dont ces paramètres peuvent être
	positionnés et stockés dans l'image du noyau via 'rdev' est aussi
	décrite.

<sect2>Le paramètre `ramdisk_size='
<p>

	Bien que ce soit vrai que le disque virtuel augmente sa taille de
	façon dynamique, il existe une limite maximum afin qu'il n'utilise
	pas toute la mémoire vive (RAM) disponible et vous laisse dans
	une triste situation. Par défaut, la taille est de 4096 (c.a.d. 4MB)
	qui doit être suffisant pour la plupart des besoins. Vous pouvez
	écraser cette taille par défaut pour une plus grande ou une plus
	petite avec ce paramètre de démarrage.

	Voyez le fichier <tt>linux/Documentation/ramdisk.txt</tt>
	pour une description complète des nouveaux paramètres de démarrage,
	et comment les utiliser. La façon dont ces paramètres peuvent être
	positionnés et stockés dans l'image du noyau via 'rdev' est aussi
	décrite.

<sect2>Le paramètre `ramdisk=' (obsolete)
<p>

	NOTE&nbsp;: Ce paramètre est obsolète, et ne doit pas être utilisé exepté
	sur les noyaux v1.3.47 et ceux plus anciens. Les commandes que l'on peut
	utiliser pour les disques virtuels sont documentées ci-dessous.

	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 fichiers racine sur une disquette 1.44 Mo chargé
	sur le disque virtuel, vous devrez utiliser&nbsp;:

<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</tt>.	

<sect2>Le paramètre `noinitrd' (disque RAM initial)
<p>

	La version v2.x  du noyau et les versions plus récentes
	possédent la caractéristique de pouvoir avoir le système de fichiers
	racine initialement sur un disque virtuel, et le noyau exécute
	<tt>linuxrc</tt> sur cette image mémoire. Cette caractéristique est
	généralement utilisée pour permettre de charger des modules
	nécessaires au montage du système de fichiers racine réél (par
	exemple&nbsp;: charger les modules du pilote SCSI stockés dans l'image
	du disque virtuel, et alors monter le système de fichiers racine
	réél sur un disque SCSI).

	Le paramètre `noinitrd' actuel détermine ce qui arrive aux données
	initrd après que le noyau ait démarré. Lorsqu'il est indiqué,
	au lieu de se convertir en disque virtuel, il est accessible via
	<tt>/dev/initrd</tt>, et peut-être lu juste avant que la RAM soit
	libérée pour le système. Pour de plus amples détails sur l'utilisation
	du disque RAM initial, consultez <tt>linux/Documentation/initrd.txt</tt>.
	De plus, les versions les plus récentes <tt>LILO</tt> et <tt>LOADLIN</tt>
	doivent contenir des informations complémentaires très intéressantes.

<sect1>Paramètres de Démarrage relatifs à la Gestion de la Mémoire.
<p>

	Les paramètres suivants modifient la façon dont linux détecte ou gère
	la mémoire physique et virtuelle de votre système.

<sect2>Le paramètre `mem='
<p>

	Ce paramètre vise deux objectifs&nbsp;: L'objectif principal est
	d'indiquer la quantité de mémoire installée (ou une valeur plus
	petite si vous désirez limiter le quantité de mémoire disponible
	pour linux). Le second ojectif (très utilisé) est de spécifier
	<tt>mem=nopentium</tt> qui indique au noyau de linux de ne pas utiliser
	les caractéristiques de la table de performance de pages de 4&nbsp;MO
	(4MB page table performance).

	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&nbsp;Mo (Hé oui, encore une manque de
	prévoyance, tout comme les disques de 1024 cylindres...Pfffff). Linux
	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&nbsp;Mo de mémoire vive
	installée, vous pouvez utiliser ce paramètre de démarrage pour indiquer à
	Linux quelle est la quantité de mémoire dont vous disposez. Voici une
	citation de Linus sur l'utilisation du paramètre <tt/`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&nbsp;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&nbsp;Mo
	comme mémoire adressable. Le contraire est aussi exact&nbsp;: 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&nbsp;:
	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</tt> mais échouer avec soit
	<tt>mem=98304k</tt> ou <tt>mem=96M</tt>.


<sect2>Le paramètre `swap='
<p>

	Il permet à l'utilisateur de régler certains des paramètres de la mémoire
	virtuelle qui sont liés aux fichiers d'échange (swap) sur disque.
	Il accepte les huit paramètres suivants&nbsp;:

<code>
	MAX_PAGE_AGE
	PAGE_ADVANCE
	PAGE_DECLINE
	PAGE_INITIAL_AGE
	AGE_CLUSTER_FRACT
	AGE_CLUSTER_MIN	
	PAGEOUT_WEIGHT
	BUFFEROUT_WEIGHT 
</code>

	Les utilisateurs avertis pourront jeter un coup d'oeuil au fichier
	<tt>linux/mm/swap.c</tt> et sur les données du répertoire
	<tt>/proc/sys/vm</tt>.

<sect2>Le paramètre `buff='
<p>

	Comme le paramètre `swap=', il permet à l'utilisateur de régler
	certains des paramètres relatifs à la gestion des tampons mémoire.
	Il accepte les six paramètres suivant&nbsp;:
 
<code>
	MAX_BUFF_AGE
	BUFF_ADVANCE
	BUFF_DECLINE
	BUFF_INITIAL_AGE
	BUFFEROUT_WEIGHT
	BUFFERMEM_GRACE	
</code>

	Les utilisateurs avertis pourront jeter un coup d'oeuil au fichier
	<tt>linux/mm/swap.c</tt> et sur les données du répertoire
	<tt>/proc/sys/vm</tt>.

<sect1>Paramètres de démarrage pour les systèmes de fichiers racine NFS
<p>

	Linux supporte des systèmes comme les stations de travail sans
	disques à condition que leur système de fichiers racine soit de
	type NFS (Network FileSystem ou Système de Fichiers Réseau).
	Ces paramètres sont utilisés pour indiquer à la station exempte
	de disque sur quelle machine elle doit aller chercher son système.
	Notez aussi que le paramètre <tt>root=/dev/nfs</tt> est requis.
	Des informations détaillées sur l'utilisation d'un système de
	fichiers racine NFS sont contenues dans
	<tt>linux/Documentation/nfsroot.txt</tt>. Je vous conseille de lire
	ce fichier, car ce qui suit est juste un résumé rapide extrait
	directement de ce document.

<sect2>Le paramètre `nfsroot='
<p>

	Ce paramètre indique au noyau quelle machine, quel répertoire et quelles
	options NFS sont utilisées pour son système de fichiers racine.
	La structure du paramètre est la suivante&nbsp;:

<code>
        nfsroot=&lsqb;<server-ip>:&rsqb;<root-dir>&lsqb;,<nfs-options>&rsqb;
</code>

	Si le paramètre nfsroot n'est pas donné sur la ligne de commande, on
	utilisera par défaut `/tftpboot/&percnt;'. Les autres options sont
	les suivantes&nbsp;:

	&lt;server-ip&gt;
		- Indique l'adresse IP du serveur NFS. Si ce champ n'est pas
		indiqué, l'adresse par défaut déterminée par la variable
		nfsaddrs (voir ci-dessous) est utilisée. Une des utilisations
		de ce paramètre est par exemple l'utilisation de serveurs
		différents pour RARP et NFS. Généralement vous pouvez le
		laisser à blanc.

	&lt;root-dir&gt;
		- Nom du répertoire sur le serveur à monter en tant que racine.
		Si il y a un caractère `&percnt;' dans la chaîne, le caractère
		sera remplacé par la représentation ASCII de l'adresse IP du client.

	&lt;nfs-options&gt;
		- Options NFS standard. Toutes les options sont séparées par
		des virgules. Si le champ option n'est pas indiqué, les valeurs
		suivantes sont utilisées par défaut&nbsp;:

<verb> 
	port		= tel que donné par le démon portmap du serveur
	rsize		= 1024
	wsize		= 1024
	timeo		= 7
	retrans		= 3
	acregmin	= 3
	acregmax	= 60
	acdirmin	= 30
	acdirmax	= 60
	flags		= hard, nointr, noposix, cto, ac
</verb>

<sect2>Le paramètre `nfsaddrs='
<p>

	Ce paramètre de démarrage positionne les différentes adresses
	qui sont nécessaires à la communication sur le réseau. Si ce paramètre
	n'est pas indiqué, le noyau essaie d'utiliser RARP et/ou BOOTP pour
	calculer ces paramètres. La structure est la suivante&nbsp;:

<code>
        nfsaddrs=<my-ip>:<serv-ip>:<gw-ip>:<netmask>:<name>:<dev>:<auto>
</code>

	&lt;my-ip&gt;
		- Adresse IP du client. Si elle est vide, cette adresse sera
		déterminée par RARP ou BOOTP. Le protocole utilisé dépend de
		ce qui a été activé pendant la configuration du noyau et sur
		le paramètre &lt;auto&gt;. Si ce paramètre n'est pas vide, ni
		RARP, ni BOOTP ne seront utilisés.

	&lt;serv-ip&gt;
		- Adresse IP du serveur NFS. Si RARP est utilisé pour déterminer
		l'adresse du client et que ce paramètre N'EST PAS vide, seules
		les réponses du serveur spécifié seront acceptées. Pour utiliser
		différents serveurs NFS et RARP, indiquez votre serveur RARP ici
		(ou laissez le à blanc), et indiquez votre serveur NFS dans
		le paramètre nfsroot (voir ci-dessus). Si cette entrée est à
		blanc, l'adresse utilisée est celle du serveur qui répond à la
		requête RARP ou BOOTP.

	&lt;gw-ip&gt;
		- Adresse IP d'une passerelle (gateway) si le serveur est sur
		un sous-réseau différent. Si cette entrée est vide, aucune
		passerelle n'est utilisée et le serveur est supposé être sur
		le réseau local, à moins qu'une valeur n'ait été reçue par BOOTP.

	&lt;netmask&gt;
		- Masque de réseau pour les interfaces de réseau local. Si ce
		paramètre est vide, le masque de réseau est déduit de l'adresse
		IP du client, à moins qu'une valeur n'ait été reçue par BOOTP.

	&lt;name&gt;
		- Nom du client. Si il est vide, l'adresse IP du client est
		utilisée en notation ASCII, sauf si une valeur a été reçue par
		BOOTP.

	&lt;dev&gt;
		- Nom du périphérique réseau à utiliser. Si le paramètre est vide,
		tous les périphériques sont utilisés pour les requêtes RARP,
		et le premier trouvé pour BOOTP. Pour NFS, le périphérique
		utilisé est celui pour lequel on a reçu une réponse à RARP ou
		BOOTP. Si vous n'avez qu'un périphérique, vous pouvez sans aucun
		risque le laisser à blanc.

	&lt;auto&gt;
		- Méthode à utiliser pour l'autoconfiguration. Si `rarp' ou
		`bootp' sont indiqués, le protocole spécifié est utilisé.
		Si la valeur est `both' ou vide, les deux protocoles seront
		utilisés à condition qu'ils aient été activés durant la
		configuration du noyau. Utiliser 'none' signifie pas
		d'autoconfiguration; Dans ce cas, vous devez indiquer toutes
		les valeurs nécessaires dans les champs précédents.

	Le paramètre &lt;auto&gt; peut apparaître seul comme valeur du paramètre
	nfsaddrs (sans tous les caractères `:' avant). Dans ce cas,
	l'autoconfiguration est utilisée. Toutefois, la valeur `none'
	n'est pas disponible dans ce cas.  

<sect1>D'autres paramètres de démarrage divers
<p>

	Ces différents paramètres de démarrage permettent à l'utilisateur de
	gérer certains paramètres internes du noyau.


<sect2>Le paramètre `debug'
<p>

	Le noyau envoie des messages importants (et moins importants)
	à l'opérateur via la fonction <tt>printk()</tt>. Si le message est
	considéré comme important, la fonction <tt>printk()</tt> envoie une
	copie sur la console active, mais le transmet aussi à la fonction
	<tt>klogd()</tt> qui l'archive sur le disque. La raison pour laquelle
	le message est envoyé à la console et archivé sur disque, est
	simple&nbsp;: 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</tt>.
	Par défaut, l'affichage sur la console est déclenché pour tout ce
	qui depasse le <tt>DEBUG</tt> (niveau 7). Ces niveaux sont définis dans
	le fichier include <tt>kernel.h</tt>. Le fait de spécifier comme
	paramètre de démarrage <tt>debug</tt> forcera le niveau de suivi
	à 10, de façon que <em>tous</em> 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()</tt>.
	Consultez la page du manuel correspondant à la version installée
	sur votre système, pour voir comment utiliser ce programme.


<sect2>Le paramètre `init='
<p>

	Par défaut, le noyau lance le programme `init' au démarrage,
	qui prend alors soin de configurer l'ordinateur pour les utilisateurs
	en lançant les programmes getty, les scripts `rc' et tout le reste.
	Le noyau recherche d'abord <tt>/sbin/init</tt>, ensuite
	<tt>/etc/init</tt> (secondaire), et en dernier recours, il essaiera
	d'utiliser <tt>/bin/sh</tt> (éventuellement <tt>/etc/rc</tt>).
	Si par exemple, votre programme init est corrompu et donc stoppé vous
	serez en mesure de démarrer, en utilisant le paramètre de démarrage
	<tt>init=/bin/sh</tt> qui vous positionnera directement dans un shell
	au démarrage, vous permettant de remplacer les programmes corrompus.


<sect2>Le Paramètre `no387'
<p>

	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éversible lorsqu'elles
	font des calculs un virgule flottante, apparemment dû à un bug dans
	les instructions FRSAV/FRRESTOR. 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 !
	Cela peut aussi être intéressant si vous possédez une de ces
	<em>très</em> vielles machines 386 qui peuvent utiliser une FPU 80287,
	alors que <bf>Linux</bf> ne peut pas.

<sect2>Le Paramètre `no-hlt'
<p>

	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&nbsp;: elles ne peuvent pas retourner en mode opérationnel
	de façon fiable après que cette instruction ait é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 </em> 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.


<sect2>Le paramètre `no-scroll'
<p>

	L'utilisation de ce paramètre au démarrage désactive le défilement
	d'écran (scrolling) qui rend difficile l'emploi de terminaux Braille.


<sect2>Le paramètre `panic='
<p>

	Dans le cas très désagréable d'une alerte du noyau (kernel panic),
	c'est à dire une erreur interne qui a été détectée par le noyau, et
	pour laquelle il a décidé qu'elle était suffisamment grave
	pour râler bruyamment et tout arrêter ; le comportement par défaut
	est d'en rester là jusqu'à ce que quelqu'un se penche sur le problème,
	visualise le message sur l'écran et redémarre la machine.
	Cependant, si une machine fonctionne sans surveillance dans un local
	isolé il peut-être souhaitable qu'il redémarre de lui-même afin que la
	machine revienne en ligne. Par exemple, l'utilisation de <tt/`panic=30'/
	au démarrage forcera le noyau à essayer de redémarrer 30 secondes
	après que l'alerte du noyau se soit produite. Une valeur à zéro donne
	le comportement par défaut, qui est d'attendre éternellement.
	Notez que cette valeur d'attente peut aussi être lu et positionnée
	via l'interface sysctl <tt>/proc/sys/kernel/panic</tt>.

<sect2>Le paramètre `profile='
<p>

	Les développeurs du noyau peuvent activer une option qui leur permet
	de suivre comment et ou le noyau consomme ses cycles CPU, dans le but
	d'augmenter ses capacités et ses performances. Cette option vous permet
	de positionner cet indicateur de suivi au moment du démarrage.
	Généralement il est positionné à deux. Vous pouvez aussi compiler
	votre noyau avec l'option de suivi par défaut. Dans tous les cas,
	il vous faudra un outil comme <tt>readprofile.c</tt> afin d'utiliser
	les données fournies par <tt>/proc/profile</tt>.

<sect2>Le paramètre `reboot='
<p>

	Cette option contrôle le type de redémarrage que Linux fera lorsque
	vous ferez une remise à zéro de votre ordinateur (généralement
	via <tt>/sbin/init</tt> en faisant un Ctrl-Alt-Suppr).
	Le comportement par défaut des derniers noyaux v2.0 est de faire
	un redémarrage `à froid' (c.a.d. remise à zéro complète, le BIOS
	comtrôle la mémoire, etc.) au lieu d'un redémarrage `à chaud'
	(c.a.d pas de remise à zéro totale, pas de contrôle de la mémoire).
	Il a été modifié pour prendre la valeur froid par défaut depuis
	que cela semble fonctionner sur des matériels bon marché ou
	endommagés qui ne voulaient pas redémarrer lorsqu'un redémarrage à
	chaud était requis. Pour retrouver l'ancien comportement (c.a.d
	redémarrage à chaud) utilisez <tt>reboot=w</tt> en fait n'importe quel
	mot commançant par <tt>w</tt> fonctionnera.

	Pourquoi cela pourrait-il vous ennuyer ? Certains disques incluant
	de la mémoire cache peuvent détecter un redémarrage à chaud, et écrire
	les données du cache sur le disque. Lors d'un redémarrage à froid,
	la carte peut-être remise à zéro, et les données stockées dans la
	mémoire cache seront perdues. D'autres ont signalé que des systèmes
	prenaient beaucoup de temps pour vérifier la mémoire, et/ou des
	BIOS SCSI qui étaient très long à s'initialiser lors d'un démarrage
	à froid, et c'est par conséquent une excellente raison pour
	utiliser le redémarrage à chaud.

<sect2>Le paramètre `reserve='
<p>

	Ceci est utilisé pour <em>protéger</em> les zones des
	ports d'I/O des  programmes de test.
	La syntaxe de la commande est la suivante&nbsp;:

<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</em> 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</tt> 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 (avec le nom <tt>reserved</tt>).
	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 qui font un <tt>check_region()</tt> au lieu
	de tester aveuglément une région d'entrée/sortie. 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</tt> 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</tt> 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 <tt>0x300-0x31f</tt>.

	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</tt>. Plusieurs ordres <tt>reserve</tt>
	peuvent être utilisés si vous avez une requête vraiment très complexe.

<sect2>Le paramètre `vga='
<p>

	Notez que ce n'est pas vraiment un paramètre de démarrage. C'est une
	option interprétée par LILO et non pas par le kernel, contrairement à
	tous les autres arguments. Pourtant, son utilisation est devenue si
	commune qu'une mention lui est réservée ici. Il peut aussi être positionné
	grâce à <tt>rdev -v</tt> ou par equivalence avec <tt>vidmode</tt> sur
	le fichier vmlinuz. Cela permet au programme de configuration d'utiliser
	le BIOS vidéo pour changer le mode d'écran par défaut, avant le démarrage
	du noyau de Linux. Les modes courants sont 80x50, 132x44, etc. Le
	meilleur moyen d'utiliser cette option est de demarrer avec
	<tt>vga=ask</tt>, qui vous demandera à l'aide d'une liste des différents
	modes que vous pourrez utiliser avec votre carte vidéo, avant de démarrer
	le noyau. Une fois que vous avez le nombre que vous voulez utiliser,
	provenant de la liste ci-dessus, vous pouvez, plus tard, le placer à la
	place de 'ask'. Pour plus d'informations, veuillez, s'il vous plait,
	regarder le fichier <tt>linux</tt>Documentation/svga.txt/ qui existe
	depuis les dernières versions du noyau.  Notez que les noyaux récents
	(version 2.1 et supérieures) ont leur programme de configuration qui
	permettent de changer le mode vidéo, sous la forme d'une option, listée
	comme un <em>Support de sélection de mode vidéo</em> (<em>Video mode
	selection support</em>), donc vous devez sélectionner cette option si
	vous voulez cette  caractéristique.


<sect>Paramètres de démarrage pour les Périphériques SCSI
<p>

	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.


<sect1>Paramètres pour les pilotes de niveau intermédiaire
<p>

	Les pilotes de niveau intermédiaire prennent en charge des choses
	comme le disques, les CD-Roms et les bandes sans s'attacher aux
	spécificitées de chaque périphériques.


<sect1>Nombre maximum de LUN contrôlés (`max_scsi_luns=')
<p>

	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 bandes 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 Bandes SCSI (`st=')
<p>

	Certaines configurations de démarrage pour les lecteurs de bande SCSI
	peuvent être obtenues en utilisant ce qui suit&nbsp;:	 

<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</tt> est 32 ko, et la taille maximum
	qui peut être donnée est la valeur ridicule de 16384 ko.
	La zone <tt>write_threshold</tt> 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'utilisationnbsp;:   

<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>Paramètres pour les adaptateurs SCSI
<p>
	Notations utilisées dans cette section&nbsp;:

	<tt>iobase</tt>  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> à <tt>0x3ff</tt>.

	<tt>irq</tt>  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>dma</tt>  Le canal DMA (Direct Memory Access - Accès Direct à la Mémoire)
	Généralement appliqué aux cartes de pilotage du bus. Les cartes PCI et VLB
	pilotent directement le bus, et ne nécessitent pas de canal DMA ISA.

	<tt>scsi-id</tt>  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</tt>  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'informations. 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.


<sect2>Adaptec aha151x, aha152x, aic6260, aic6360, SB16-SCSI (`aha152x=')
<p>

	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&nbsp;:

<code>
         aha152x=iobase&lsqb;,irq&lsqb;,scsi-id&lsqb;,reconnect&lsqb;,parity&rsqb;&rsqb;&rsqb;&rsqb;
</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&nbsp;:   

<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.  

<sect2>Adaptec aha154x (`aha1542=')
<p>

	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&lsqb;,buson,busoff&lsqb;,dmaspeed&rsqb;&rsqb;
</code>

	Les valeurs couramment utilisées pour <tt>iobase</tt> sont les suivantes&nbsp;:
	<tt>0x130, 0x134, 0x230, 0x234, 0x330, 0x334</tt>.
	Des clones de cartes peuvent autoriser d'autres valeurs.

	Les valeurs <tt>buson, busoff</tt> 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</tt> 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.

<sect2>Adaptec aha274x, aha284x, aic7xxx (`aic7xxx=')
<p>

	Ces cartes peuvent recevoir un paramètre selon la syntaxe suivante&nbsp;:   

<code>
	aic7xxx=extended,no_reset
</code>

	La valeur de <tt>extended</tt>, 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</tt>, 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.


<sect2>Adaptateurs SCSI AdvanSys (`advansys=')
<p>

	Le pilote AdvanSys peut accepter jusqu'à quatre adresses I/O
	qui seront testées pour une carte SCSI AdvanSys. Notez que ces
	valeurs (si elles sont utilisées) n'auront en aucun cas d'effet
	sur les tests EISA ou PCI.
	Elles sont seulement utilisées pour tester les cartes ISA et VLB.
	De plus, si le pilote a été compilé avec l'option de débogage
	activée, le niveau de détail des informations renvoyées par le
	débogage peut être indiqué en ajoutant un paramètre
	<tt>0xdeb[0-f]</tt>. Le <tt>0-f</tt> permet de faire afficher
	les 16 niveaux de messages de débogage.

<sect2>Adaptateur Always IN2000 (`in2000=')
<p>

	Contrairement aux autres paramètres de démarrage, le pilote IN2000
	utilise des préfixes de type chaîne ASCII pour la plupart de ses
	paramètres entiers; Voici la liste des paramètres acceptés&nbsp;:

	ioport:addr

		- Où addr est l'adresse IO d'une carte (généralement sans
		mémoire morte 'ROM').

	noreset

		- Pas de paramètres optionnels. Evite la remise à zéro du
		bus SCSI au moment du démarrage.

	nosync:x

		- x est un masque d'octets (bitmask) ou les 7 premiers bits
		correspondent aux 7 périphériques SCSI possibles (bit 0 pour
		le périphérique &num;0, etc). Positionnez un bit pour
		PREVENIR une négociation de synchronisation sur ce périphérique.
		Par défaut sync est DESACTIVE sur tous les périphériques.

	period:ns

		- ns est la durée minimum en nanosecondes d'une période
		de transfert de données en SCSI. La valeur par défaut est
		500; les valeurs doivent être comprises entre 250 et 1000.

	disconnect:x

		- x = 0 pour ne jamais autoriser les déconnexions, 2 pour
		toujours les autoriser. x = 1 fait des déconnexions 'selon
		le besoin', ce qui est la valeur par défaut et
		généralement le meilleur choix.

	debug:x
		- Si `DEBUGGING_ON' est positionné, x est un masque d'octets
		qui provoque différents types de sorties de débogage
		pour imprimer (voyez le DB_xxx définis dans in2000.h).

	proc:x
		 - Si `PROC_INTERFACE' est défini, x est un masque d'octets
		qui indique comment fontionne l'interface /proc
		et ce qu'elle fait (voir la définition de PR_xxx dans
		in2000.h

	Quelques exemples d'utilisation sont listés ci-dessous&nbsp;:

<code>
	in2000=ioport:0x220,noreset
	in2000=period:250,disconnect:2,nosync:0x03
	in2000=debug:0x1e
	in2000=proc:3 
</code>

<sect2>Matériel basé sur un AMD AM53C974 (`AM53C974=')
<p>

	Contrairement aux autres pilotes, celui-ci n'utilise pas de
	paramètres de démarrage pour indiquer les E/S, les IRQ ou les
	DMA (depuis que le AM53C974 est un périphérique PCI, il n'a
	pas besoin de la faire).
	En revanche, les paramètres sont utilisés pour communiquer les
	modes de transfert et les vitesses qui doivent être utilisés entre
	le serveur (host) et le périphérique cible. Utilisons un exemple
	pour y voir plus clair&nbsp;:

<code>
	AM53C974=7,2,8,15
</code>

	Ceci peut être interprété de la manière suivante&nbsp;:

	`Pour communiquer entre le contrôleur d'identifiant SCSI-ID 7
	et le périphérique d'identifiant SCSI-ID 2, un taux de transfert
	de 8 MHz en mode synchrone, avec un décalage maximum de 15 octets
	doit être négocié.' De plus amples détails peuvent être trouvés
	dans le fichier <tt>linux/drivers/scsi/README.AM53C974</tt>   

<sect2>Les serveurs SCSI BusLogic avec les noyaux v1.2 (`buslogic=')
<p>

	Dans les anciens noyaux, les pilotes buslogic n'acceptent qu'un seul
	paramètre, qui est l'adresse d'entrée/sortie. Elle doit correspondre
	à l'une des valeurs suivantes&nbsp;:

	<tt>0x130, 0x134, 0x230, 0x234, 0x330, 0x334</tt>.

<sect2>Les serveurs SCSI BusLogic aves les noyaux v2.x (`BusLogic=')
<p>

	Avec les noyaux v2.x, le pilote BusLogic accepte de nombreux
	paramètres (notez la casse ci dessus ; B et L majuscule !!!).
	La description détaillée qui suit est extraite directement du
	pilote de Leonard N. Zubkoff inclus dans le noyau v2.0&nbsp;.

	Pour le pilote BusLogic, une ligne de commande destinée au noyau
	comprend l'identifiant du pilote "BusLogic=" éventuellement
	suivi par une série d'entiers séparés par des virgules, et
	accessoirement par une suite de chaines aussi séparées par des
	virgules. Chaque ligne de commande s'applique à un adaptateur
	BusLogic. Des lignes de commande multiples peuvent être utilisées
	sur des systèmes utilisant plusieurs cartes BusLogic.

	Le premier entier indiqué est l'adresse d'Entrée/Sortie (I/O
	Address) à laquelle l'adaptateur est situé. Si il n'est pas
	spécifié, il est positionné à zéro, ce qui indique d'appliquer
	cette ligne de commande au premier adaptateur BusLogic trouvé
	lors de la séquence de détection. Si une adresse I/O est fournie
	sur la ligne de commande, la séquence de détection est ignorée.

	Le second entier fourni est la profondeur de la 'Tagged Queue'
	à utiliser pour les périphériques cibles qui utilisent le 'Tagged
	Queuing'. La profondeur de cette file correspond au
	nombre de commandes SCSI qui peuvent être envoyées simultanément
	pour être éxécutées. Si rien n'est indiqué, la valeur par défaut
	est zéro, et indique d'utiliser une valeur déterminée automatiquement
	en fonction du 'Total Queue Depth' de l'adaptateur, ainsi que du
	nombre, du type, de la vitesse des périphériques cible détectés.
	Pour les adaptateurs qui requièrent des 'ISA Bounce Buffers',
	le 'Tagged Queue Depth' est automatiquement positionné
	à 'BusLogic_TaggedQueueDepth_BB' pour éviter une préallocation
	excessive de mémoire 'DMA Bounce Buffer'. Les périphériques
	cibles qui ne supportent pas le 'Tagged Queuing' utilisent une 'Queue
	Depth' ayant pour valeur 'BusLogic_UntaggedQueueDepth'.

	Le troisième entier est le 'Bus Settle Time' (temps de stabilisation
	du bus) en secondes. C'est le temps à attendre entre une remise
	à zéro physique de l'adaptateur, qui initialise une remise à
	zéro du bus SCSI, et le moment où l'on peut passer une commande
	SCSI. Si rien n'est indiqué, il est à zéro par défaut, ce qui
	indique d'utiliser la valeur BusLogic_DefaultBusSettleTime.

	Le quatrième entier correspond aux options locales. Si rien n'est
	indiqué, la valeur par défaut est 0. Notez que ces options locales
	sont uniquement utilisées sur un adaptateur hôte spécifique.

	Le cinquième entier correspond aux options globales. Si rien n'est
	indiqué, le valeur par défaut est 0. Notez que les options globales
	sont appliquées à tous les adaptateurs hôtes.

	Les chaînes d'options sont utilisées pour contrôler le 'Tagged
	Queuing', le recouvrement d'erreur, et le test de l'adaptateur
	hôte.

	Les indications pour le 'Tagged Queuing' commencent par "TQ:"
	et permettent d'indiquer précisemment où le 'Tagged Queuing' est
	autorisé sur les périphériques cibles qui le supportent. Les
	spécifications suivantes sont disponibles&nbsp;:

	TQ:Default

		- Le 'Tagged Queuing' sera permis, basé sur la version
		de micro-code de l'adaptateur hôte BusLogic et conditionné
		par la valeur de 'Tagged Queue Depth' qui doit permettre
		la mise en file d'attente de multiples commandes.

	TQ:Enable

		- Le 'Tagged Queuing' est activé pour tous les périphériques
		de cet adaptateur hôte, outrepassant toutes les limitations
		qui seraient imposées par la version de micro-code de
		cet adaptateur.

	TQ:Disable

		- Le 'Tagged Queuing' sera désactivé pour tous les
		périphériques reliés à cet adaptateur hôte.

	TQ:&lt;Per-Target-Spec&gt;

		- Le 'Tagged Queuing' sera contrôlé individuellement pour
		chaque périphérique cible. &lt;Per-Target-Spec&gt; est une
		séquence de caractères "Y", "N", et "X". "Y" active le 'Tagged
		Queuing', "N" désactive le 'Tagged Queuing', et
		"X" correspond à la valeur par défaut basée sur la version
		du micro-code. Le premier caractère correspond au
		périphérique cible 0, le second au périphérique cible 1,
		et ainsi de suite ; Si la séquence de caractères "Y",
		"N", et "X" ne suffit pas pour tous les périphériques cibles,
		les caractères non-indiqués prendront la valeur "X".

	Notez que la demande explicite de 'Tagged Queuing' peut conduire
	à des problèmes. Cette capacité est fournie principalement pour
	permettre de désactiver le 'Tagged Queuing' sur des périphériques
	qui ne l'utilisent pas correctement.

	Les indications de la Stratégie de Recouvrement d'Erreurs commencent
	par "ER:" et permettent d'indiquer l'action de recouvrement d'erreur
	à effectuer quand la 'ResetCommand' est appellée en raison d'un
	incident sur une commande SCSI, de façon à finir correctement.
	Les options suivantes sont disponibles&nbsp;:

	ER:Default

		- Le Recouvrement d'Erreur choisira entre la remise à zéro
		physique (Hard Reset) et la remise à zéro du bus des
		périphériques (Bus Device Reset) selon les recommandations
		du sous système SCSI.

	ER:HardReset

		- Le Recouvrement d'Erreur demandera une remise à zéro
		physique de l'adaptateur hôte, ce qui provoquera aussi
		une remise à zéro du bus SCSI.

	ER:BusDeviceReset

		- Le recouvrement d'Erreur enverra un message 'Bus Device
		Reset' (remise à zéro du bus) individuellement au
		périphérique provoquant l'erreur. Si le Recouvrement
		d'Erreur est à nouveau appelé pour ce périphérique, et
		qu'aucune commande SCSI de ce périphérique n'a été éxecutée
		avec succès depuis le dernier message 'Bus Device Reset'
		a été envoyé, alors une remise à zéro physique est provoquée.

	ER:None

		- Le Recouvrement d'Erreur sera supprimé. Cette option
		peut seulement être sélectionnée si un 'SCSI Bus Reset'
		ou un 'Bus Device Reset' provoque un plantage du
		périphérique cible de façon totale et irrécupérable.

	ER:&lt;Per-Target-Spec&gt;

		- Le Recouvrement d'Erreur sera contrôlé individuellement
		pour chaque périphérique.  &lt;Per-Target-Spec&gt; est
		une séquence de caractères "D", "H", "B", et "N". "D"
		correspond à 'Default', "H" à 'Hard Reset', "B" à 'Bus
		Device Reset', et "N" à 'None'. Le premier caractère
		correspond au périphérique 0 , le second au périphérique 1,
		et ainsi de suite. Si la séquence de caractères "D", "H",
		"B", et "N" ne suffit pas pour tous les périphériques
		possibles, les carractères manquants correspondront à "D".

	Les spécifications de test de l'adaptateur hôte sont les suivantes&nbsp;:

	NoProbe
		- Aucun test d'aucune sorte ne doit être fait, et par
		conséquent, aucun adaptateur hôte BusLogic ne sera détecté.

	NoProbeISA
		- Aucun test des adresses I/O standard ISA ne sera fait,
		et par conséquent, seuls les adaptateurs hôtes PCI seront détectés.

	NoSortPCI
		- Les adaptateurs hôtes PCI seront énumérés dans l'ordre
		fourni par le BIOS PCI, ignorant tous les paramètres de
		l'option "Utilisation du &num; des bus et périphériques
		pour la séquence d'analyse du bus PCI" de l'AutoSCSI.

<sect2>Les cartes SCSI EATA (`eata=')
<p>

	Depuis la déjà ancienne version v2.0 du noyau, les pilotes EATA
	acceptent un paramètre de démarrage permettant d'indiquer les
	adresses d'entrée/sortie qui doivent être testées. Il est de la
	forme&nbsp;:

<code>
        eata=iobase1&lsqb;,iobase2&rsqb;&lsqb;,iobase3&rsqb;...&lsqb;,iobaseN&rsqb;
</code>

	Le pilote testera les adresses dans l'ordre où elles sont fournies.

<sect2>Future Domain TMC-8xx, TMC-950 (`tmc8xx=')
<p>

	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&nbsp;:

<code>
	tmc8xx=mem_base,irq
</code>

	La valeur <tt>mem_base</tt> 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&nbsp;:

	<tt>0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000</tt>.

<sect2>Future Domain TMC-16xx, TMC-3260, AHA-2920 (`fdomain=')
<p>

	Le pilote détecte ces cartes selon une liste connue de signatures
	de BIOS ROM. Pour obtenir une liste complète des révisions connues
	de BIOS, voyez le fichier <tt>linux/drivers/scsi/fdomain.c</tt>
	qui contient beaucoup d'informations en début de fichier. Si votre
	BIOS n'est pas connu du pilote, vous pourrez utiliser un forçage
	de la façon suivante&nbsp;:

<code>
        fdomain=iobase,irq&lsqb;,scsi_id&rsqb;
</code>

<sect2>Le lecteur ZIP IOMEGA / Port Parallèle (`ppa=')
<p>

	Ce pilote est pour l'adaptateur SCSI de l'IOMEGA Port Parallèle
	qui est intégré dans le lecteur IOMEGA ZIP. Il peut aussi fonctionner
	avec le périphérique d'origine IOMEGA PPA3. Le paramètre de démarrage
	pour ce pilote a la structure suivante&nbsp;:

<code>
	ppa=iobase,speed_high,speed_low,nybble
</code>

	où tous les paramètres sont facultatifs, sauf 'iobase'. Si vous
	souhaitez modifier un des trois éléments, il serait bon de lire
	au préalable le document <tt>linux/drivers/scsi/README.ppa</tt>
	afin d'obtenir des détails sur ces paramètres.

<sect2>Contrôleurs utilisant un NCR5380 (`ncr5380=')
<p>

	Selon votre carte, le 5380 peut-être soit 'i/o mapped' ou 'memory
	mapped' (répertorié en entrée/sortie ou répertorié en mémoire).
	Une adresse en dessous de 0x400 indique souvent l'i/o mapping,
	cependant, les matériels PCI et EISA utilisent des adresses
	d'entrée/sortie au dessus de 0x3ff. Dans tous les cas, vous indiquez
	l'adresse, la valeur de l'IRQ, et la valeur du canal DMA. Un exemple
	pour une carte 'i/o mapped' serait&nbsp;: <tt>ncr5380=0x350,5,3</tt>. 
	Si la carte n'utilise pas les interruptions, une valeur d'IRQ 255
	(<tt>0xff</tt>) désactivera les interruptions. Une IRQ à 254 indiquera
	d'activer l'autotest. Des détails supplémentaires sont fournis dans
	le document <tt>linux/drivers/scsi/README.g_NCR5380</tt>.

<sect2>Contrôleurs utilisant un NCR53c400 (`ncr53c400=')
<p>

	Le support du 53c400 est fait avec le même pilote que le support
	du 5380 mentionné ci-dessus. Le paramètre de démarrage est
	identique au précédent, sauf qu'aucun canal DMA n'est utilisé par
	le 53c400.

<sect2>Contrôleurs utilisant un NCR53c406a (`ncr53c406a=')
<p>

	Ce pilote utilise un paramètre de démarrage de la forme suivante&nbsp;: 

<code>
	ncr53c406a=PORTBASE,IRQ,FASTPIO	
</code>

	où les paramètres IRQ et FASTPIO sont optionnels. Une valeur
	d'interruption à zéro désactive l'utilisation des interruptions.
	L'utilisation d'une valeur à 1 pour FASTPIO active l'utilisation
	des instructions <tt>insl</tt> et <tt>outsl</tt> au lieu des instructions
	mono-octet <tt>inb</tt> et  <tt>outb</tt>. Le pilote peut aussi utiliser
	le DMA comme une option utilisée lors de la compilation (compile-time
	option).  

<sect2>Pro Audio Spectrum (`pas16=')
<p>

	La PAS16 utilise une puce NCR5380 SCSI, et les nouveaux modèles peuvent
	être configurés de façon logicielle. La syntaxe du paramètre est la
	suivante&nbsp;:

<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</tt>
	est généralement <tt>0x388</tt>.

<sect1>Seagate ST-0x (`st0x=')
<p>

	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&nbsp;:

<code>
	st0x=mem_base,irq
</code>

	La valeur de <tt>mem_base</tt> 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&nbsp;:
	<tt>0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000</tt>.

<sect1>Trantor T128 (`t128=')
<p>

	Cette carte est aussi conçue autour de la puce NCR5380, et accepte les options suivantes&nbsp;:

<code>
	t128=mem_base,irq
</code>

	Les valeurs autorisées pour <tt>mem_base</tt> sont les suivantes&nbsp;:
	<tt>0xcc000, 0xc8000, 0xdc000, 0xd8000</tt>.

<sect2>Cartes SCSI Ultrastor (`u14-34f=')
<p>

	Notez que pour cette carte tout se présente sous la forme de deux
	pilotes indépendants, nommés <tt>CONFIG_SCSI_U14_34F</tt> qui utilise
	<tt>u14-34f.c</tt> et <tt>CONFIG_SCSI_ULTRASTOR</tt> qui utilise
	<tt>ultrastor.c</tt>. C'est le u14-34f qui (jusqu'au dernier noyau v2.0)
	accepte un paramètre de démarrage de la forme&nbsp;:

<code>
        u14-34f=iobase1&lsqb;,iobase2&rsqb;&lsqb;,iobase3&rsqb;...&lsqb;,iobaseN&rsqb;
</code>

	Le pilote autotestera les adresses dans l'ordre dans lequel
	elles apparaissent.

<sect2>Cartes Western Digital WD7000 (`wd7000=')
<p>

	Le test du pilote pour le wd7000 cherche une chaine connue de BIOS ROM
	et connait quelques réglages standards de configuration.
	Si il ne retrouve pas les valeurs correctes pour votre carte, ou
	que vous avez une version de BIOS non reconnue, vous pouvez utiliser
	le pramètre suivant&nbsp;:

<code>
	wd7000=irq,dma,iobase
</code>

<sect1>Cartes n'acceptant pas les paramètres de démarrage
<p>

	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.

<verb> 
	Adaptec aha1740 (autotest EISA), 
	NCR53c7xx, 8xx (PCI, toutes les deux) 
	Qlogic Fast (0x230, 0x330)
	Qlogic ISP (PCI)
</verb>


<sect>Disque Durs
<p>

	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
<p>

	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 nouvelles puces ou celles qui sont défectueuses.
	Ce qui suit est un résumé des paramètres de démarrage possibles.
	Pour plus de détails, il faut <em>absolument</em> consulter le fichier
	<tt>ide.txt</tt> dans le répertoire <tt>linux/Documentation</tt>, duquel
	ce résumé est extrait.

<code>

 "hdx="  est reconnu pour toutes les valeurs de "x", de "a" to "h", comme "hdc".
 "idex=" est reconnu pour toutes les valeurs de "x" de "0" à "3", comme "ide1".

 "hdx=noprobe"		: le lecteur est peut-être présent, mais ne pas le tester
 "hdx=none"		: le lecteur n'est PAS présent, ignorer le cmos et
		          ne pas tester.
 "hdx=nowerr"		: ignorer le bit WRERR_STAT sur ce lecteur
 "hdx=cdrom"		: le lecteur est présent, et c'est un cdrom
 "hdx=cyl,head,sect"    : le lecteur est présent, avec la description indiquée
 "hdx=autotune"	   	: le pilote essaiera de régler la vitesse de l'interface
		      	  pour atteindre le plus rapide des modes PIO supportés,
		       	  si possible pour ce lecteur seulement.
			  Ce n'est pas supporté par tous les types de puces,
		     	  et peut de temps en temps poser des problèmes avec
			  les disques IDE anciens ou originaux.

 "idex=noprobe"	  	: ne pas tenter d'accéder ou utiliser cette interface
 "idex=base"		: tester l'interface à l'adresse indiquée,
		     	  où "base" est généralement 0x1f0 ou 0x170
			  et "ctl" est considéré comme étant "base"+0x206
 "idex=base,ctl"	: indiquer les deux, base et ctl
 "idex=base,ctl,irq"	: indiquer les valeurs de base, ctl, et irq
 "idex=autotune"	: le pilote tentera de régler la vitesse de l'interface
			  pour atteindre le plus rapide des modes PIO supportés,
			  pour tous les lecteurs de cette interface.
		     	  Ce n'est pas supporté par tous les types de puces,
		  	  et peut de temps en temps poser des problèmes avec
			  les disques IDE anciens ou originaux.

 "idex=noautotune"      : le pilote n'essaiera PAS de régler la vitesse
			  de l'interface. Ceci est la valeur par défaut pour
		      	  le plupart des puces, excepté le cmd640.
 "idex=serialize"       : ne pas empièter sur les opérations sur idex et ide(x^1)

</code>

	Les suivants sont valides SEULEMENT pour ide0, et les valeurs par
	défaut pour base, ctl et ports ne doivent pas être modifiés.

<code>

 "ide0=dtc2278"		: teste/supporte l'interface DTC2278
 "ide0=ht6560b"	   	: teste/supporte l'interface HT6560B
 "ide0=cmd640_vlb"	: *REQUIS* pour les cartes VLB avec la puce CMD640
		          (pas pour PCI - automatiquement détecté)
 "ide0=qd6580"	      	: teste/supporte l'interface qd6580
 "ide0=ali14xx"	  	: teste/supporte les puces ali14xx (ALI M1439/M1445)
 "ide0=umc8672"	       	: teste/supporte les puces umc8672

</code>

	Tout le reste est rejeté par un message "BAD OPTION" (mauvaise option).

<sect1>Options du pilote standard ST-506 (`hd=') 
<p>

	Le pilote standard 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&nbsp;:

<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=')
<p>

	Si vous êtes 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&nbsp;:

<code>
	xd=type,irq,iobase,dma_chan
</code>

	La valeur de <tt>type</tt> indique qui est le constructeur de la carte et peut
	prendre les valeurs suivantes&nbsp;: 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()</tt> 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&nbsp;:

<code>
	xd=2,5,0x320,3
</code>

<sect>CD-ROMs (Non-SCSI/ATAPI/IDE)
<p>

	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 ces
	types de CD-ROMs.

	Notez que la plupart de ces CD-ROM ont des fichiers de documentation
	que vous <em>devriez</em> lire, et ils sont tous dans le répertoire&nbsp;:
	<tt>linux/Documentation/cdrom</tt>.

<sect1>L'interface Aztech (`aztcd=')
<p>

	La syntaxe pour ce type de carte est&nbsp;:

<code>
        aztcd=iobase&lsqb;,magic_number&rsqb;
</code>

	Si vous positionnez le <tt>magic_number</tt> (nombre magique) à <tt>0x79</tt>
	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=')
<p>

	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&nbsp;:

<code>
        cdu31a=iobase,&lsqb;irq&lsqb;,is_pas_card&rsqb;&rsqb;
</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, mais on peut aussi
	ne pas l'indiquer.

<sect1>L'interface Sony CDU-535 (`sonycd535=')
<p>

	La syntaxe pour cette interface de CD-ROM est&nbsp;:

<code>
        sonycd535=iobase&lsqb;,irq&rsqb;
</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=')
<p>

	La syntaxe pour cette interface de CD-ROM est&nbsp;:

<code>
	gscd=iobase
</code>

<sect1>L'interface standard Mitsumi (`mcd=')
<p>

	La syntaxe pour cette interface de CD-ROM est&nbsp;:

<code>
        mcd=iobase,&lsqb;irq&lsqb;,wait_value&rsqb;&rsqb;
</code>

	La valeur <tt>wait_value</tt> 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, ou non, être implémentée en fonctions d'une
	instruction <tt>DEFINE</tt> lors de la compilation.

<sect1>L'interface ISP16 (`isp16=')
<p>

	la syntaxe pour cette interface de CD-ROM est&nbsp;:

<code>
        isp16=&lsqb;port&lsqb;,irq&lsqb;,dma&rsqb;&rsqb;&rsqb;&lsqb;&lsqb;,&rsqb;drive_type&rsqb;
</code>

	Utiliser une valeur à 0 pour <tt>irq</tt> ou <tt>dma</tt> signifie qu'ils
	ne sont pas utilisés. Les valeurs possibles pour <tt>drive_type</tt>
	sont <tt>noisp16, Sanyo, Panasonic, Sony,</tt> et <tt>Mitsumi</tt>.
	L'utilisation de <tt>noisp16</tt> désactive les lecteurs totalement.  

<sect1>L'interface Mitsumi XA/MultiSession (`mcdx=')
<p>

	Pour l'instant, ce pilote `expérimental' possède une fonction de
	configuration mais aucun paramètre n'est encore implémenté
	(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=')
<p>

	La syntaxe pour ce type de carte est&nbsp;:

<code>
	optcd=iobase
</code>

<sect1>L'interface Phillips CM206 (`cm206=')
<p>

	La syntaxe pour ce type de carte est&nbsp;:

<code>
        cm206=&lsqb;iobase&rsqb;&lsqb;,irq&rsqb;
</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</tt> et <tt>0x370</tt>, vous
	pouvez donc spécifier un ou deux nombres, dans n'importe quel ordre.
	Il accepte aussi `cm206=auto' pour activer l'autotest.

<sect1>L'interface Sanyo (`sjcd=')
<p>

	La syntaxe pour ce type de carte est&nbsp;:

<code>
        sjcd=iobase&lsqb;,irq&lsqb;,dma_channel&rsqb;&rsqb;
</code>

<sect1>L'interface SoundBlaster Pro (`sbpcd=')
<p>

	La syntaxe de ce type de carte est&nbsp;:

<code>
	sbpcd=iobase,type
</code>

	Où <tt>type</tt> prend une des valeurs suivantes (Attention&nbsp;: le respect des
	majuscules et des minuscules est important)&nbsp;: `SoundBlaster',
	`LaserMate', ou `SPEA'.
	L'adresse d'entrée/sortie de base est celle de l'interface de CD-ROM,
	et <em>non</em> celle de la partie son de la carte.

<sect>Autres Périphériques Matériels
<p>

	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=')
<p>

	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&nbsp;:

<code>
        ether=irq,iobase&lsqb;,param_1&lsqb;,param_2,...param_8&rsqb;&rsqb;&rsqb;,name
</code>

	Le premier argument non-numérique est pris comme nom.
	La valeur <tt>param_n</tt> (si elle est applicable) a généralement
	des significations différentes pour chaque carte/pilote.
	Les valeurs courantes de <tt>param_n</tt> 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 de forcer
	le test d'une seconde carte ethernet, alors que par défaut on en
	teste une seule. Ceci peut être accompli avec un simple ordre&nbsp;:

<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.

	NOTE IMPORTANTE POUR LES UTILISATEURS DE MODULES&nbsp;: ce qui est indiqué
	ci-dessus <em>ne forcera pas</em> un autotest pour une seconde si vous
	utilisez les pilotes de périphériques en tant que modules chargeables
	au moment de l'exécution (au lieu de les avoir compilés dans le noyau).
	La plupart des distributions de Linux utilisent un noyau
	central dépouillé combiné avec une large sélection de pilotes
	modulaires. Le paramètre <tt>ether=</tt> s'applique seulement aux pilotes
	compilés directement dans le noyau.

	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</tt> 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.
	<url url="http://sunsite.unc.edu/mdw/HOWTO/Ethernet-HOWTO.html"
	name="Ethernet-HowTo"> 

<sect1>Le pilote du Lecteur de Disquettes (`floppy=')
<p>

	Il existe de nombreuses options pour le pilote du lecteur de disquette,
	et qui sont listées dans le fichier <tt>README.fd</tt> dans le répertoire
	<tt>linux/drivers/block</tt>. Cette information est extraite directement
	du fichier.


	floppy=mask,allowed_drive_mask

	Positionne le <sq>bitmask</sq> (masque binaire) des lecteurs autorisés
	à la valeur <tt>mask</tt>. 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.


	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.


	floppy=asus_pci

	Positionne le <sq>bitmask</sq> uniquement aux unités autorisées 0 et 1.
	(Par défaut)


	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.


	floppy=0,daring

	Indique au pilote du lecteur de disquette que votre contrôleur doit
	être utilisé avec précaution.


	floppy=one_fdc

	Indique au pilote de lecteur de disquette que vous n'avez qu'un contrôleur de
	lecteur de disquette (Par défaut).


	floppy=two_fdc <em>ou</em> floppy=address,two_fdc

	Indique au pilote de 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.


	floppy=thinkpad

	Indique au pilote de 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).


	floppy=0,thinkpad

	Indique au pilote de lecteur de disquette que vous ne possédez pas
	un Thinkpad.


	floppy=drive,type,cmos

	Positionne le type cmos du <tt>drive</tt> à <tt>type</tt>.
	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.


	floppy=unexpected_interrupts

	Imprime un message d'alerte lorsqu'une interruption inattendue est
	reçue (comportement par défaut).


	floppy=no_unexpected_interrupts <em>or</em> 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=')
<p>

	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 (était décrit ? )
	dans le fichier <tt>Readme.Linux</tt>, dans le répertoire
	<tt>linux/drivers/sound</tt>.
	Il accepte de recevoir un paramètre de la forme&nbsp;:

<code>
        sound=device1&lsqb;,device2&lsqb;,device3...&lsqb;,device11&rsqb;&rsqb;&rsqb;
</code>

	Où chaque valeur de <tt>deviceN</tt> est de la forme <tt>0xTaaaId</tt>,
	et les octets sont utilisés de la façon suivante&nbsp;:

	T - type de périphérique&nbsp;: 1=FM, 2=SB, 3=PAS, 4=GUS, 5=MPU401, 6=SB16,
	7=SB16-MPU401

	aaa - adresse d'entrée/sortie en hexadécimal.

	I - ligne d'interruption en hexadécimal (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=')
<p>

	Le pilote des souris sur bus accepte un seul paramètre, qui est
	la valeur de l'IRQ matérielle à utiliser.  

<sect1>Le pilote MS Bus Mouse (`msmouse=')
<p>

	Le pilote MS mouse accepte un seul paramètre, qui correspond à l'IRQ
	à utiliser.

<sect1>Le pilote d'imprimantes (`lp=')
<p>

	Depuis le noyau 1.3.75, vous pouvez indiquer au pilote d'imprimante
	quels sont les ports qu'il doit utiliser et ceux qu'il <em>ne doit
	pas</em> utiliser. Vous devriez l'utiliser si vous ne voulez pas que le
	pilote demande tous les ports parallèles disponibles, alors que
	d'autres pilotes (c.a.d. PLIP, PPA) peuvent aussi les utiliser.

	Le format du paramètre est des paires i/o, IRQ. Par exemple,
	<tt>lp=0x3bc,0,0x378,7</tt> utilisera le port d'adresse 0x3bc
	en mode IRQ-less (élection), et utilisera l'IRQ 7 pour le port
	d'adresse 0x378. Le port 0x278 (si il y en a un) ne sera pas testé,
	jusqu'à ce que l'autotest soit utilisé en l'absence d'un paramètre
	`lp=' argument. Pour désactiver totalement le pilote d'impression,
	on peut utiliser <tt>lp=0</tt>.

<sect1>Le pilote ICN ISDN (`icn=')
<p>

	Le pilote ISDN nécessite un paramètre de démarrage de la forme
	suivante&nbsp;:

<code>
	icn=iobase,membase,icn_id1,icn_id2
</code>

	où <tt>iobase</tt> est l'adresse du port d'entrée/sortie de la carte,
	<tt>membase</tt> est l'adresse de base de la mémoire partagée de la
	carte, et les deux <tt>icn_id</tt> sont des chaines d'identification
	ASCII uniques.

<sect1>Le pilote PCBIT ISDN (`pcbit=')
<p>

	Ce paramètre de démarrage utilise des paires de valeurs de la forme&nbsp;:

<code>
        pcbit=membase1,irq1&lsqb;,membase2,irq2&rsqb;
</code>

	où <tt>membaseN</tt> est l'adresse de base de la mémoire partagée de
	la Nième carte, et <tt>irqN</tt> est l'interruption de la Nième carte.
	La valeur par défaut est IRQ 5 et l'adresse de base <tt>0xD0000</tt>.

<sect1>Le pilote Teles ISDN (`teles=')
<p>

	Le pilote ISDN nécessite un paramètre de démarrage de la forme
	suivantenbsp;:

<code>
	teles=iobase,irq,membase,protocol,teles_id
</code>

	où <tt>iobase</tt> est l'adresse du port e/s de la carte, <tt>membase</tt>
	est l'adresse de base de la mémoire partagée, <tt>irq</tt> est le canal
	d'interruption utilisé par la carte, et <tt>teles_id</tt> est l'identifiant
	ASCII unique.

<sect1>Le pilote DigiBoard (`digi=')
<p>

	Le pilote DigiBoard accepte une chaine de six identifiants ou entiers
	séparés par des virgules. Les 6 valeurs dans l'ordre sont&nbsp;:

<verb> 
	Active/Désactive la carte
	Type de la carte&nbsp;: PC/Xi(0), PC/Xe(1), PC/Xeve(2), PC/Xem(3)
	Active/Désactive la mise en ordre alternative des broches
	Nombre de ports sur cette carte
	Port E/S sur lequel la carte est configurée  (en HEXA si on
	utilise des chaines d'identification)
	Adresse de base de la fenêtre mémoire (en HEXA si on utilise les
	chaines d'identification)
</verb>

	Un exemple de paramètre de démarrage correct (dans ses deux formes)
	est&nbsp;:

<code>
	digi=E,PC/Xi,D,16,200,D0000
	digi=1,0,0,16,512,851968   
</code>

	Notez que le pilote prend les valeurs par défaut de <tt>0x200</tt>
	pour l'i/o et pour la mémoire partagée <tt>0xD0000</tt> en l'absence de
	paramètre de démarrage <tt>digi=</tt>. Il n'y a pas d'autotest effectué.
	Plus de détails peuvent être trouvés dans le fichier
	<tt>linux/Documentation/digiboard.txt</tt>.

<sect1>le pilote RISCom/8 Multiport Serial (`riscom8=')
<p>

	Jusqu'à quatre cartes peuvent être supportées en fournissant une
	valeur d'E/S unique pour chaque carte installée. Les autres détails
	pourront-être trouvés dans le fichier
	<tt>linux/Documentation/riscom8.txt</tt>.

<sect1>Le modem Série/Parallèle Radio Baycom (`baycom=')
<p>

	Le format du parmètre de démarrage pour ces périphériques est de
	la forme&nbsp;:

<code>
        baycom=modem,io,irq,options&lsqb;,modem,io,irq,options&rsqb;
</code>

	Utiliser modem=1 signifie que vous avez le périphérique ser12,
	modem=2 signifie que vous avez le périphérique par96. Utiliser
	options=0 signifie l'utilisation du DCD matériel, et options=1
	signifie l'utilisation du DCD logiciel. L'<tt>io</tt> et l'<tt>irq</tt>
	sont l'adresse I/O de base du port, et la valeur de l'interruption.
	Il y a plus de détails dans le fichier <tt>README.baycom</tt> qui
	est généralement dans le répertoire <tt>/linux/drivers/char/</tt>.


<sect>Conclusion
<p>

	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</tt>

	Merci de faire parvenir vos remarques sur la traduction de ce document à
	Laurent Renaud, <tt>lrenaud@hol.fr</tt>

	(<tt>http://wwwperso.hol.fr/&tilde;lrenaud</tt>)

</article>
