  kerneld mini-HOWTO
  par Henrik Storner storner@osiris.ping.dk
  Version 1.6, 6 Avril 1997

  (Adaptation francaise par Eric Dumas dumas@freenix.fr, 19 Avril 1997).

  11..  IInnttrroodduuccttiioonn

  Ce document presente comment utiliser les fonctionnalites  de  kerneld
  dans les noyaux Linux. Il detaille :

  +o  ce qu'est kerneld ;

  +o  pourquoi vous voulez vous en servir ;

  +o  comment recuperer les differents outils necessaires ;

  +o  comment les configurer ;

  +o  comment  configurer  kerneld  a propos des modules qu'il ne connait
     pas ;

  +o  comment espionner kerneld (peut-etre  utile  lors  de  la  mise  en
     place) ;

  +o  connexions a la demande _v_i_a PPP et SLIP ;

  +o  utilisation speciale de kerneld ;

  +o  problemes courants et dysfonctionnements.

  La   derniere   version   de   ce   document  peut  etre  trouvee  sur
  _h_t_t_p_:_/_/_e_o_l_i_c_o_m_._o_l_i_c_o_m_._d_k_/ _s_t_o_r_n_e_r_/_k_e_r_n_e_l_d_-_m_i_n_i_-_H_O_W_T_O_._h_t_m_l.  Entre deux
  diffusions   de  ce document, vous pouvez trouver des mises-a-jour sur
  ma    liste    non     triee     des     modifications     a     l'Url
  _h_t_t_p_:_/_/_e_o_l_i_c_o_m_._o_l_i_c_o_m_._d_k_/ _s_t_o_r_n_e_r_/_k_e_r_n_._h_t_m_l.

  22..  AAuutteeuurr eett ccoonnttrriibbuutteeuurrss

  Si  vous  remarquez que des erreurs se sont glissees dans ce document,
  envoyez-moi un courrier  a  ce  sujet.  Les  personnes  suivantes  ont
  contribuees a ce mini-HowTo :

  +o  Bjorn Ekwall, bj0rn@blox.se ;

  +o  Ben Galliart, bgallia@luc.edu ;

  +o  Cedric Tefft, cedric@earthling.net ;

  +o  Brian Miller bmiller@netspace.net.au.

  Je suis ouvert a tout encouragement, remarque ou suggestion envoye par
  mes lecteurs...

  33..  QQuu''eesstt--ccee qquuee kkeerrnneelldd ??

  kerneld est une fonctionnalite introduite pendant le developpement des
  noyaux 1.3 par Bjorn Ekwall. Il est inclus dans tous les noyaux 2.0 et
  2.1. Il permet au noyau d'etre constitue de modules,  comme  pour  les
  gestionnaires de peripheriques, les gestionnaires reseau, les systemes
  de fichiers, pour qu'ils  soient  charges  automatiquement  lorsqu'ils
  sont  necessaires plutot que d'avoir a les installer manuellement avec
  modprobe ou insmod.

  kerneld possede egalement d'autres fonctions :

  +o  Il peut  lancer  un  programme  a  chaque  fois  que  vous  essayez
     d'acceder au reseau. Cela facilite l'implementation de la connexion
     sur demande d'acces au reseau si vous etes  connecte  par  SLIP  ou
     PPP.

  Et  pour certains aspects plus gadgets, meme s'ils ne sont pas (encore
  ?)  integres dans le noyau standard :

  +o  il peut etre utilise pour executer un programme  utilisateur  a  la
     place  de  l'economiseur  d'ecran  standard,  ce  qui  vous  permet
     d'utiliser un programme personnel ;

  +o  la  gestion  de  l'economiseur  d'ecran  peut  etre  modifiee  pour
     transformer   le   "beep"   de  la  console  en  quelque  chose  de
     completement different...

  kerneld est constitue de deux entites distinctes :

  +o  gestion dans le noyau Linux pour envoyer des requetes au demon pour
     savoir si un module doit etre utilise pour certaines taches ;

  +o  un  demon en mode utilisateur qui trouve quels modules doivent etre
     charges pour repondre a une requete du noyau.

  Ces  deux  parties  doivent  fonctionner  ensemble  pour  que  kerneld
  fonctionne convenablement. Une seule des deux ne suffit pas.

  44..  PPoouurrqquuooii eesstt--ccee qquuee jjee vvoouuddrraaiiss mm''eenn sseerrvviirr ??

  Il  existe  un certain nombre de bonnes raisons pour utiliser kerneld.
  Les  premieres  que  je  vais  donner   sont  personnelles.   D'autres
  personnes en ont surement d'autres :

  +o  si  avez  a  construire  des  noyaux  pour  plusieurs  systemes qui
     different peu, comme par  exemple  s'ils  ont  des  cartes  reseaux
     differentes, alors vous pouvez construire un seul noyau et quelques
     modules au lieu d'avoir a recompiler un noyau par systeme ;

  +o  les modules simplifient le travail de test pour les developpeurs  :
     ce  n'est  pas  la  peine  de  reamorcer la machine pour charger et
     decharger le peripherique (cela s'applique a tous les  modules,  et
     pas uniquement a ceux que kerneld charge) ;

  +o  cela  reduit  la  place  memoire qu'utilise le noyau, vous laissant
     plus de place pour vos applications. La  memoire  utilisee  par  le
     noyau  n'est  jjaammaaiiss  swapee,  donc si vous avez 100 Ko inutilement
     utilise par des gestionnaires que vous n'utilisez pas, ils  gachent
     de la memoire pour rien.

  +o  certains  gestionnaires  que  j'utilise,  comme  pour le lecteur de
     disquettes/cartouches ou le gestionnaire iBCS ne  sont  disponibles
     que  sous  la forme de modules. Mais je ne veut pas m'embeter a les
     charger et a les decharger a chaque fois que j'en ai besoin.

  +o  les personnes qui  creent  les  distributions  Linux  n'ont  pas  a
     generer   plusieurs   centaines   d'images   differentes  :  chaque
     utilisateur n'a qu'a charger les  modules  dont  il  a  besoin.  Ce
     systeme est utilise avec l'installation de la RedHat 4.0.

  Bien  sur,  il existe certaines raisons pour lesquelles vous ne voulez
  pas l'utiliser. Vous pouvez par exemple preferer n'avoir qu'un seul et
  unique  fichier  pour  votre  noyau  avec tous les gestionnaires qui y
  soient inclus. Dans ce cas, vous ne lisez pas le bon document.

  55..  OOuu rreeccuuppeerreerr lleess eelleemmeennttss nneecceessssaaiirreess ??

  La gestion dans le noyau Linux a ete introduit dans Linux  1.3.57.  Si
  vous  avez une version plus ancienne du noyau, vous devrez le mettre a
  jour  si  vous  souhaitez  utiliser  kerneld.  Tous  les  sites  Linux
  possedent  les  sources  du  noyau.  Je  vous recommande de prendre la
  derniere version stable pour 2.0 (actuellement, la 2.0.29).

    ftp://sunsite.unc.edu/pub/Linux/kernel/v2.0/linux-2.0.29.tar.gz
    ftp://tsx-11.mit.edu/pub/linux/sources/system/v2.0/linux-2.0.29.tar.gz
    ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/v2.0/linux-2.0.29.tar.gz
    ftp://ftp.ibp.fr/pub/linux/kernel/sources/v2.0/linux-2.0.29.tar.gz

  Le  demon  en  mode  utilisateur  est   inclus   dans   le   paquetage
  modules-1.2.8,  et avec le paquetage plus recent modules-2.0. Ils sont
  normalement disponibles aux meme endroits, mais  les  sites  officiels
  sont :

    ftp://sunsite.unc.edu/pub/Linux/kernel/modules-2.0.0.tar.gz
    ftp://tsx-11.mit.edu/pub/linux/sources/sbin/modules-2.0.0.tar.gz
    ftp://ftp.funet.fi/pub/Linux/tools/modules-2.0.0.tar.gz

  Note  :  si  vous  souhaitez utiliser le chargement de module avec les
  noyaux de developpement 2.1, utilisez le dernier  paquetage  modutils-
  et  pas modules-. Voir un peu plus loin la partie dediee aux problemes
  rencontres avec les noyaux 2.1.

  66..  CCoommmmeenntt llee ccoonnffiigguurreerr ??

  Tout d'abord, recuperez les paquetages necessaires :  un  noyau  assez
  recent  et  la  derniere  version  des  utilitaires  pour les modules.
  Ensuite, installez-les. C'est assez simple : desarchivez le  paquetage
  et  lancez  make  install.  Cette  operation  compile  et installe les
  differents programmes dans le repertoire  /sbin  :  genksysm,  insmod,
  lsmod,  modprobe,  depmod,  kerneld.   Je  vous  recommande  d'ajouter
  quelques lignes dans vos scripts  d'amorcage  /etc/rc.d/rc.S  si  vous
  utilisez  la  Slackware,  ou  /etc/rc.d/rc.sysinit  (si  vous utilisez
  SysVinit, c'est a dire Debian, RedHat, Caldera) :

          # Lancer kerneld - cette operation doit se produire
          # le plus tot possible lors de l'amorcage de la machine
          # et en tout cas avant que fsck ne soit lance sur les
          # systemes de fichiers car certaines partitions peuvent
          # avoir besoin de modules.
          if [ -x /sbin/kerneld ]
          then
                  /sbin/kerneld
          fi

          # Vos fsck peuvent se trouver ici, ainsi que votre
          # commande mount pour monter la racine en lecture, ecriture

          # Mise a jour du fichier des dependances des modules
          # Votre racine DOIT etre montee en lecture ecriture !
          if [ -x /sbin/depmod ]
          then
                  /sbin/depmod -a
          fi

  La premiere partie de ce script lance kerneld.

  La seconde appelle depmod -a. Ce programme construit la liste de  tous
  les modules disponibles et analyse leurs dependances, de telle maniere
  que l'on sache si un module a besoin qu'un autre module  soit  charge,
  et eventuellement le charger, et ainsi de suite.

  Note  : des versions recentes de kerneld ont une option de compilation
  lui permettant d'utiliser la bibliotheque _d_b_m GNU,  libgdbm.  Si  vous
  activez  cette option, Cela signifie que ce demon ne sera lance que si
  la bibliotheque libgdbm est disponible, ce qui peut ne pas etre le cas
  si  vous avez le repertoire /usr sur une partition separee et que vous
  lanciez kerneld avant que /usr ne soit monte. La solution  recommandee
  est de deplacer la bibliotheque du repertoire /usr/lib vers /lib.

  Ensuite,   desarchivez   les   sources   du  noyau,  configurez-le  et
  construisez le noyau. Si vous n'avez  jamais  fait  cela  avant,  vous
  devriez  absolument  lire  le fichier README qui se trouve a la racine
  des sources de Linux. Lorsque vous lancez make config pour  configurer
  le  noyau,  faites  attention  aux differentes questions que l'on vous
  pose :

    Enable loadable module support (CONFIG_MODULES) [Y/n/?] Y

  Vous devez absolument activer (et donc  repondre  YY)  la  gestion  des
  modules, ou bien kerneld n'aura aucun module a charger.

    Kernel daemon support (CONFIG_KERNELD) [Y/n/?] Y

  Activer  cette  option  est  bien  evidement  necessaire. Ensuite, bon
  nombre de choses dans le noyau peuvent etre construites sous la  forme
  de modules, et vous verrez donc ce genre de question :

    Normal floppy disk support (CONFIG_BLK_DEV_FD) [M/n/y/?]

  Vous  pouvez  repondre  par  MM, comme "Module". En principe, seuls les
  gestionnaires de peripheriques qui sont  absolument  necessaires  pour
  amorcer votre machine, comme le gestionnaire du disque dur, le systeme
  de fichier de la racine, devraient etre inclus dans le noyau. Le reste
  peut tres bien etre construit comme module.

  Lorsque vous en avez termine avec make config, alors lancez

  make dep ; make clean ; make zImage ; make modules ; make modules_install

  ou

  make zlilo ; make modules ; make modules_install

  Et  allez  gracieusement  vous  restaurer  ou boire un cafe (enfin, ca
  depend de votre machine)...

  make   zImage   met   l'image   de   votre    nouveau    noyau    dans
  arch/i386/boot/zImage.   Vous  aurez  besoin  de  le  copier  ou  vous
  conservez vos images, ou bien installez-le via LILO.

  Pour plus d'informations concernant la construction et  l'installation
  de   vos   noyau,  consultez  le  Kerneld-Howto  (N.d.T.  :  egalement
  disponible en version francaise) qui est regulierement poste  dans  le
  forum   Usent   comp.os.linux.answers,   et  disponible  sur  le  site
  sunsite.unc.edu dans le repertoire /pub/Linux/docs/HOWTO.

  77..  TTeesstteerr kkeerrnneelldd

  Maintenant, reamorcez votre machine avec le nouveau noyau. Lorsque  le
  systeme  a  termine  son  initialisation,  lancez  un  ps -ax, et vous
  devriez alors voir une ligne concernant kerneld :

      PID TTY STAT  TIME COMMAND
       59  ?  S     0:01 /sbin/kerneld

  Un des interets de kerneld c'est qu'une fois que vous avez compile  le
  noyau  et  bien  installe  le  demon,  tres  peu  de configuration est
  necessaire. Pour commencer, essayez d'utiliser un des gestionnaires de
  peripheriques  que  vous  avez construit comme un module - il est fort
  probable que cela fonctionnera directement  sans  avoir  a  configurer
  quelque  chose de plus. Par exemple, j'ai construit le gestionnaire du
  lecteur de disquette sous la forme de module, donc je peux inserer une
  disquette au format DOS et faire :

    osiris:~ $ mdir a:
     Volume in drive A has no label
     Volume Serial Number is 2E2B-1102
     Directory for A:/

    binuti~1 gz       1942 02-14-1996  11:35a binutils-2.6.0.6-2.6.0.7.diff.gz
    libc-5~1 gz      24747 02-14-1996  11:35a libc-5.3.4-5.3.5.diff.gz
            2 file(s)        26689 bytes

  Cela  prouve  bien  que  le  gestionnaire  du  lecteur  de  disquettes
  fonctionne bien et qu'il a  ete  charge  automatiquement  par  kerneld
  lorsque j'ai essaye d'utiliser le lecteur de disquettes.

  Pour  voir  quel  module  a  veritablement  ete  charge,  executez  le
  programme /sbin/lsmod qui vous donne la liste des modules charges :

    osiris:~ $ /sbin/lsmod
    Module:        #pages:  Used by:
    floppy            11    0 (autoclean)

  Le mot-clef _(_a_u_t_o_c_l_e_a_n_) signifie que le  module  sera  automatiquement
  decharge  par  kerneld  s'il  n'a  pas  ete utilise pendant plus d'une
  minute. De cette maniere, les 11 pages memoires (c'est a dire 44 Ko  :
  une page correspond a 4 Ko) ne seront utilisees que pendant l'acces au
  lecteur de disquettes. Ensuite, elles seront liberees, ce qui est tres
  pratique  si vous etes un peu court en memoire pour vos applications !

  88..  CCoommmmeenntt kkeerrnneelldd ssaaiitt qquueellss mmoodduulleess aa cchhaarrggeerr ??

  Bien que kerneld connaisse un  peu  les  types  de  modules  les  plus
  courants,  il  y a certaines situations ou kerneld ne sait pas comment
  gerer une requete en provenance du  noyau.   C'est  le  cas  avec  les
  gestionnaire  de  CD-ROM  ou  les  gestionnaires  reseau  :  il existe
  plusieurs types de modules qui peuvent etre charges.

  Les requetes que le demon recoit du noyau concernent l'un des elements
  suivant :

  +o  un gestionnaire de peripherique bloc ;

  +o  un gestionnaire de peripherique caractere ;

  +o  un format de binaire  ;

  +o  une discipline de ligne tty ;

  +o  un systeme de fichier ;

  +o  une route reseau (pour etablir une liaison ppp ou slip) ;

  +o  un gestionnaire de peripherique reseau ;

  +o  un service reseau (par exemple rarp) ;

  +o  un protocole reseau (par exemple IPX).

  kerneld  determine  quel  module  doit  etre  charge  en consultant le
  fichier de  configuration  /etc/conf.modules.  Il  existe  deux  types
  d'entrees  dans  ce  fichier : des chemins d'acces (ou les fichiers de
  modules se trouvent), et des aliases  (quels  modules  devraient  etre
  charges). Si vous ne possedez pas ce fichier, vous devriez le creer en
  executant :

    /sbin/modprobe -c | grep -v '^path' >/etc/conf.modules

  Si vous souhaitez  vraiment  ajouter  une  autre  directive  path  aux
  chemins par defaut, vous devez absolument inclure tous les chemins par
  defaut egalement, etant donne qu'une directive path  dans  ce  fichier
  replacera tous les chemins que modprobe connait.

  Normalement,  vous  n'avez pas a ajouter un chemin par vous-meme etant
  donne que l'ensemble  de  chemins  par  defaut  prend  en  compte  une
  configuration normale.

  D'un  autre cote, si vous souhaitez uniquement ajouter un alias ou une
  option, votre nouvelle entree dans le fichier  /etc/conf.modules  sera
  ajoutee  a  celles que modprobe connait deja. Si vous deviez redefinir
  un alias ou une option, votre nouvelle entree redefinira  celles  deja
  connues.

  88..11..  GGeessttiioonnnnaaiirreess ddee ppeerriipphheerriiqquueess mmooddee bblloocc

  Si vous lancez la commande /sbin/modprobe -c, vous obtiendrez la liste
  des   modules   connus   par   kerneld,   ainsi   que   les   requetes
  correspondantes.  Par exemple, la requete qui termine le chargement du
  gestionnaire pour le lecteur de disquettes correspond au  gestionnaire
  de peripherique qui possede comme nombre majeur 2 :

    osiris:~ $ /sbin/modprobe -c | grep floppy
    alias block-major-2 floppy

  Pourquoi  le  numero  2  ?  Tout  simplement parce que le peripherique
  correspondant au lecteur  de  disquette  /dev/fd*  utilise  le  nombre
  majeur 2 et il est de type bloc :

    osiris:~ $ ls -l /dev/fd0 /dev/fd1
    brw-rw-rw-   1 root     root       2,   0 Mar  3  1995 /dev/fd0
    brw-r--r--   1 root     root       2,   1 Mar  3  1995 /dev/fd1

  88..22..  GGeessttiioonnnnaaiirreess ddee ppeerriipphheerriiqquueess mmooddee ccaarraacctteerree

  Les gestionnaires de peripheriques se comportent de maniere similaire.
  Par exemple, le gestionnaire pour lecteur de cartouches possede  comme
  nombre majeur 27 :

    osiris:~ $ ls -lL /dev/ftape
    crw-rw----   1 root     disk      27,   0 Jul 18  1994 /dev/ftape

  Toutefois, kerneld ne connait pas ce gestionnaire par lui-meme : il ne
  le trouve pas dans la liste donnee par /sbin/modprobe -c.

  Donc, pour configurer le demon pour qu'il charge  ce  module,  il  est
  necessaire    d'ajouter    la   ligne   suivante   dans   le   fichier
  /etc/conf.modules :

    alias char-major-27 ftape

  88..33..  GGeessttiioonnnnaaiirreess ddee ccaarrtteess rreesseeaauu

  Vous pouvez egalement utiliser le nom du peripherique au lieu de _c_h_a_r_-
  _m_a_j_o_r_-_x_x_x,  _b_l_o_c_k_-_m_a_j_o_r_-_y_y_y.  Cela est particulierement utile avec les
  gestionnaires de peripheriques de  cartes  reseau.  Prenons  l'exemple
  d'une carte ne2000 etant sur eth0 qui sera donc chargee en rajoutant :

    alias eth0 ne

  Si vous devez passer des options au  peripherique  (par  exemple  pour
  donner  au module l'IRQ de la carte reseau), il suffit de rajouter une
  ligne option :

    options ne irq=5

  Cela permettra alors au module gerant les cartes ne2000 d'etre  charge
  automatiquement au lieu d'avoir a taper la ligne de commande :

    /sbin/modprobe ne irq=5

  Bien sur, ces options sont specifiques au module que vous utilisez.

  88..44..  FFoorrmmaattss ddee bbiinnaaiirreess

  Les  formats  de binaires sont geres de la meme maniere. A chaque fois
  que vous essayez d'executer un programme que  le  noyau  ne  sait  pas
  executer,  kerneld  recoit  une requete de la forme _b_i_n_f_m_t_-_x_x_x, ou _x_x_x
  est un nombre correspondant aux premiers octets de  l'executable.  Par
  exemple,  pour  gerer  le  chargement  du  module binfmt_aout pour les
  executables _Z_M_A_G_I_C _(_a_._o_u_t_) est

    alias binfmt-267 binfmt_aout

  comme le nombre magique pour les fichiers  _Z_M_A_G_I_C  est  267  (voir  le
  fichier  /etc/magic. Si vous regardez, vous trouverez 0413, mais c'est
  de l'octal).   Il  existe  en  fait  trois  variantes  des  du  format
  executable  a.out  : _N_M_A_G_I_C_, _Q_M_A_G_I_C et _Z_M_A_G_I_C.  Donc pour gerer tout a
  fait les modules binfmt_aout, il est necessaire d'avoir :

    alias binfmt-264 binfmt_aout  # executable pure (NMAGIC)
    alias binfmt-267 binfmt_aout  # executable de type demand-paged (ZMAGIC)
    alias binfmt-204 binfmt_aout  # executable de type demand-paged (QMAGIC)

  Les  formats  de  binaires  a.out,  Java   et   iBCS   sont   reconnus
  automatiquement par kerneld sans aucune configuration particuliere.

  88..55..  DDiisscciipplliinnee ddee lliiggnneess ((sslliipp,, ccsslliipp eett pppppp))

  Les  disciplines  sont  demandees  avec  _t_t_y_-_l_d_i_s_c_-_x,  ou  _x  commence
  generalement par 1  pour  SLIP,  ou  3  pour  PPP.  Il  sont  reconnus
  automatiquement par kerneld.

  A  propos  de  PPP,  si vous souhaitez que kerneld charge le module de
  compression de donnees bsd_comp, il vous  suffit  d'ajouter  les  deux
  lignes suivantes dans le fichier /etc/conf.modules :

    alias tty-ldisc-3 bsd_comp
    alias ppp0 bsd_comp

  88..66..  PPrroottooccoolleess rreesseeaauu ((IIPPXX,, AApppplleeTTaallkk eett AAXX..2255))

  Certains  protocoles  reseau  peuvent  etre  egalement charges sous la
  forme de modules. Le noyau demande a kerneld une famille de  protocole
  (par  exemple  IPX)  avec une requete de la forme _n_e_t_-_p_f_-_X ou _X est un
  nombre  determinant  la  famille  desiree.   Par   exemple,   _n_e_t_-_p_f_-_3
  correspond  a  AX.25,  _n_e_t_-_p_f_-_4  a  IPX  et  _n_e_t_-_p_f_-_5 a AppleTalk (ces
  nombres sont determines par les macros AF_AX25, AF_IPX, ..., que  l'on
  trouve   dans   les   sources  du  noyau  dans  le  fichier  d'en-tete
  include/linux/socket.h).  Pour charger automatiquement le module  IPX,
  il suffit d'utiliser une entree dans /etc/conf.modules :

    alias net-pf-4 ipx

  Consultez  egalement  la  section  traitant les problemes courant pour
  eviter certains messages d'avertissement  lors  de  l'amorcage  de  la
  machine concernant des familles de protocole inconnus.

  88..77..  SSyysstteemmeess ddee ffiicchhiieerrss

  Les  requetes  soumises  a kerneld concernant les systemes de fichiers
  sont particulierement  simples  car  elles  correspondent  au  nom  du
  systeme  de fichiers. Une utilisation classique concerne le chargement
  du module _i_s_o_f_s pour les systemes de fichiers CD-ROM, c'est a dire, le
  systeme de fichiers de type _i_s_o_9_6_6_0 :

    alias iso9660 isofs

  99..  GGeessttiioonnnnaaiirreess ddee ppeerriipphheerriiqquueess ddeemmaannddaanntt uunnee ccoonnffiigguurraattiioonn ppaarrttiicc--
  uulliieerree

  Certains  gestionnaires  de  peripheriques  demandent  un  peu plus de
  configuration depassant le simple  alias  d'un  peripherique  et  d'un
  module :

  +o  les   peripheriques   de   types   caractere   numero   10  (divers
     peripheriques) ;

  +o  les peripheriques SCSI ;

  +o  les peripheriques ayant besoin d'initialisations particulieres.

  99..11..  cchhaarr--mmaajjoorr--1100 :: SSoouurriiss,, wwaattcchhddooggss eett rraannddoomm

  Les gestionnaires de peripheriques sont  generalement  identifies  par
  leur  nombrer  majeur, par exemple pour ftape, il s'agit du numero 27,
  en mode caracteres.  Toutefois,  si  vous  consultez  les  entrees  du
  repertoire  /dev  pour  le  nombre  majeur  10 en mode caractere, vous
  verrez qu'il y a un certain nombre de peripheriques  tres  differents,
  dont :

  +o  souris de differents types (souris bus, PS/2, ...) ;

  +o  gestionnaires de peripheriques Watchdog ;

  +o  le peripherique noyau _r_a_n_d_o_m ;

  +o  l'interface APM (Advanced Power Management).

  D'une  maniere  evidente, chacun de ces peripheriques est controle par
  differents modules. Donc, kerneld utilise alors le nombre majeur et le
  nombre mineur pour utiliser ces modules :

          alias char-major-10-1 psaux     # Pour la souris PS/2
          alias char-major-10-130 wdt     # WatchDog WDT

  Vous  avez  besoin  d'une  version  du  noyau 1.3.82 ou superieur pour
  l'utiliser. Les versions precedentes ne passaient pas le nombre mineur
  a  kerneld, ce qui ne lui permettait donc pas de savoir quel module il
  devait charger.

  99..22..  CChhaarrggeerr ddeess ggeessttiioonnnnaaiirreess SSCCSSII:: ll''eennttrreeee ssccssii__hhoossttaaddaapptteerr

  Les  gestionnaires  pour  les  peripheriques  SCSI sont consitues d'un
  adaptateur pour la carte SCSI (par exemple pour une Adaptec 1542),  et
  d'un  gestionnaire  pour  le  type  de  peripheriques  SCSI  que  vous
  utilisez, comme un disque dur, un lecteur de CD-ROM ou un  lecteur  de
  cartouches.   Tous  peuvent  etre  charges  sous  la forme de modules.
  Toutefois, lorsque vous voulez acceder au lecteur de CD-ROM connecte a
  la  carte  Adaptec,  alors le noyau et kerneld savent uniquement qu'il
  est necessaire de charger le module sr_mod pour gerer le CD-ROM SCSI :
  il  ne  sait  pas  a  quel  controleur  le  CD-ROM  est connecte.  Par
  consequent, il ne sait pas charger le module de la carte SCSI.

  Pour resoudre le probleme, vous pouvez  ajouter  une  entree  pour  le
  module  du  controleur  SCSI  dans votre fichier /etc/conf.modules qui
  indique a kerneld quel module controleur SCSI il doit charger :

          alias scd0 sr_mod               # sr_mod pour SCSI CD-ROM's ...
          alias scsi_hostadapter aha1542  # ... doit utiliser le gestionnaire
                                          # de peripherique Adaptec 1542

  Cela ne fonctionne qu'avec une version du noyau 1.3.82 ou superieur.

  Si vous possedez plus d'une carte SCSI, vous n'avez pour le moment pas
  de  chance  :  il  n'existe  aucun  moyen  d'indiquer a kerneld que le
  lecteur de CD-ROM a besoin du gestionnaire Adaptec, et que le  lecteur
  de cartouches a besoin du gestionnaire BusLogic.

  99..33..   CChhaarrggeerr  uunn  mmoodduullee  eesstt  ppaarrffooiiss  iinnssuuffffiissaanntt :: ll''eennttrreeee ppoosstt--
  iinnssttaallll

  Parfois,   charger  un  module  n'est  pas  suffisant  pour  faire  le
  fonctionner correctement. Par exemple,  si  vous  avez  compile  votre
  carte  son sous la forme d'un module, il est souvent pratique de fixer
  un  certain  volume  sonore.  Le  seul  probleme,  c'est   que   cette
  initialisation  disparait lors du prochain chargement du module. Voici
  un  truc  pour  resoudre  le  probleme,  realise  par   Ben   Galliart
  (bgallia@luc.edu) :

  Cela     demande     a     installer     le    paquetage    setmix-0.1
  (_f_t_p_:_/_/_s_u_n_s_i_t_e_._u_n_c_._e_d_u_/_p_u_b_/_L_i_n_u_x_/_a_p_p_s_/_s_o_u_n_d_/_m_i_x_e_r_s_/_s_e_t_m_i_x_-_0_._1_._t_a_r_._g_z)

  Et  ensuite  a  ajouter  les  lignes   suivantes   dans   le   fichier
  /etc/conf.modules :

  post-install sound /usr/local/bin/setmix -f /etc/volume.conf

  Une  fois  que  le  module  est  charge,  kerneld  execute la commande
  specifiee apres l'entree post-install sound.   De  cette  maniere,  le
  module  sonore est configure avec la commande /usr/local/bin/setmix -f
  /etc/volume.conf.

  Cela peut etre tres utile egalement pour d'autre modules, par exemple,
  le  module  lp peut etre configure en utilisant le programme tunelp en
  ajoutant :

          post-install lp tunelp <options>

  Pour que kerneld reconnaisse ces  options,  vous  devez  posseder  une
  version 1.3.69f ou superieur.

  Note : une version precedente de ce mini-Howto definie une option pre-
  remove  qui  peut  eventuellement  etre  utilisee  pour  executer  une
  commande  juste avant que kerneld decharge un module.  Toutefois, cela
  n'a  jamais   fonctionne   et   son   utilisation   est   deconseille.
  Heureusement,  cette  option  devrait  disparaitre dans les prochaines
  versions.  L'ensemble des operations d'initialisation des modules  est
  en  cours  de  modification  en  ce  moment,  et  peut etre legerement
  different sur votre systeme au moment ou vous lisez ces lignes.

  99..44..  EEssppiioonnnneerr kkeerrnneelldd

  Si vous avez tout essaye, et que vous ne comprenez pas ce que le noyau
  demande  a  kerneld,  il  existe  une maniere de voir les requetes que
  kerneld recoit, et ainsi de comprendre ce qu'il faut  mettre  dans  le
  fichier  /etc/conf.modules.  Pour  cela, il faut utiliser le programme
  kdstat.

  Ce petit programme est livre avec le paquetage modules-1.3.57 (et plus
  recent)  mais  il  n'est  pas compile et installe par defaut.  Pour le
  compiler :

    cd /usr/src/modules-1.3.57/kerneld
    make kdstat

  Ensuite, pour faire en sorte que  kerneld affiche les informations sur
  ce qu'il est en train de faire, lancez :

    kdstat debug

  et  kerneld  commencera  a envoyer des messages sur la console sur son
  activite. Si vous essayez ensuite la commande activant un module, vous
  verrez   les  requetes  kerneld.  Elles  peuvent  etre  inserees  dans
  /etc/conf.modules et mises en alias pour le module qui en a besoin.

  Pour desactiver le debogage, lancez /sbin/kdstat nodebug.

  1100..  RReesseeaauu aavveecc uunnee ccoonnnneexxiioonn aa llaa ddeemmaannddee

  NOTE: la fonctionnalite de connexion a la  demande  a  ete  enormement
  discutee sur la liste linux-kernel aux mois de mai et de juin 1996. Il
  semble   qu'il   y   ait   quelques   conditions   particulieres    de
  fonctionnement,  et  certains  des gourous reseau ont recommande de ne
  pas utiliser kerneld pour cela. Le paquetage diald peut etre utilise a
  la  place,  et  permet  une  souplesse  plus  importante lorsqu'il est
  necessaire d'activer la connexion.

  kerneld recoit  egalement  une  requete  lorsque  le  noyau  a  besoin
  d'envoyer  des  donnees  a  travers  une  connexion  reseau dont il ne
  connait pas la route. C'est typiquement le cas si votre reseau utilise
  une connexion SLIP ou PPP qui n'est active que de temps en temps.

  La requete que kerneld recoit est sous la forme request-route a.b.c.d,
  ou _a_._b_._c_._d correspond a l'adresse IP de  la  machine  de  destination.
  kerneld   va  gerer  cette  requete  en  executant  un  script  shell,
  /sbin/request-route, avec l'adresse IP en  parametre.   Bien  souvent,
  l'adresse  IP  demandee  est  celle  de  votre serveur de nom (voir le
  fichier  /etc/resolv.conf).  A  moins  que  vous  n'ayez  plus   d'une
  connexion  reseau  (par  exemple  un  reseau Ethernet et une connexion
  modem), vous pouvez sans probleme ignorer cette adresse IP : tous  les
  acces  reseau doivent se comporter de la meme maniere, et il n'y a pas
  lieu de faire une difference entre les requetes pour  telle  ou  telle
  adresse.

  Pour implementer la connexion a la demande, vous devez tout simplement
  modifier  le  script  /sbin/request-route  pour  qu'il   utilise   une
  connexion  SLIP  ou  PPP.  Pour  SLIP,  cela  utilise  generalement le
  programme dip (ou autre), pour appeler le serveur SLIP et  activer  la
  connexion.  Pour  PPP,  vous  utiliserez probablement chat et pppd. Le
  script n'a pas a se soucier s'il doit charger ou pas les  modules  PPP
  ou SLIP : c'est automatise par kerneld.

  Appeler  votre  fournisseur d'acces et configurer votre connexion SLIP
  ou PPP peut mettre un peu de temps, et peut eventuellement echouer. Le
  script  request-route  possede  donc  un systeme de temporisation, par
  defaut fixe a 60 secondes, qui determine le temps d'attente  du  noyau
  pour  obtenir  la  connexion.  Bien  souvent,  la  configuration prend
  beaucoup moins de temps, donc pour obtenir une reponse la plus  rapide
  possible,  vous  devriez  vous arranger a annuler la temporisation des
  que la connexion est etablie. Les utilisateur de SLIP  peuvent,  s'ils
  utilisent une version recente de dip, se servir de la commande :

    shell kill `cat /tmp/request-route`

  juste avant la commande mode SLIP dans le script DIP.

  Les utilisateur de PPP peuvent faire un

    kill `cat /tmp/request-route`

  dans leur script /etc/ppp/ip-up.

  Si votre reseau met plus de 60 secondes pour se configurer, alors vous
  devrez changer la duree du timer dans le  script  /sbin/request-route.
  Dans  ce  cas, vous aurez besoin de modifier le delais de dechargement
  des modules non utilises de kerneld, en  ajoutant  l'option  delay=xxx
  dans  le  fichier  qui lance le demon (par exemple /etc/rc.d/rc.S). La
  valeur _x_x_x correspond au temps d'inactivite d'un module avant qu'il ne
  soit  decharge,  en secondes (par defaut, c'est 60).  C'est necessaire
  si vous utilisez PPP : les modules ppp sont charges des que  le  demon
  pppd   est  lance.  Mais  si  vous  utilisez  une  commande  du  genre
  /usr/sbin/pppd connect `chat -f /etc/chat.script` ...  alors le  demon
  pppd  reste  inactif pendant l'execution du script.  Donc, les modules
  PPP peuvent etre decharges avant que le script ne se  termine  (NdT  :
  lorsque la connexion est longue par exemple, cela se produit souvent).

  kerneld ne sait pas comment rendre compte de  l'activite  reseau  pour
  couper  la  connexion.  Toutefois,  les  utilisateur  de  PPP  peuvent
  utiliser l'option idle-disconnect de pppd introduite dans  la  version
  ppp-2.2.0.  Si vous utilisez cette option : idle-disconnect 600, alors
  la  connexion  PPP  sera  coupee  apres  600  secondes  (10   minutes)
  d'inactivite  reseau.  Les  utilisateurs  de  SLIP  devront  couper la
  liaison manuellement.

  1111..  UUttiilliissaattiioonnss ppaarrttiiccuulliieerree ddee kkeerrnneelldd

  Je savais bien que vous  alliez  me  demander  comment  configurer  le
  module d'economiseur d'ecran...

  Le  repertoire  kerneld/GOODIES  du paquetage modules-2.0.0 possede un
  certain nombre de patches pour le noyau  pour  modifier  l'economiseur
  d'ecran ainsi que le "beep" de la console.  Ce ne sont pas des patches
  officiels, donc vous devez les installer et recompiler le noyau.

  Pour installer un patch, utilisez la commande "patch" :

    cd /usr/src/linux
    patch -s -p1 < /usr/src/modules-2.0.0/kerneld/GOODIES/blanker_patch

  Ensuite, recompilez le noyau et installez le nouveau noyau.

  Lorsqu'il est temps de lancer l'economiseur d'ecran,  kerneld  lancera
  la  commande  /sbin/screenblanker.  Cela peut etre un script qui lance
  votre economiseur d'ecran favoris.

  Lorsque le noyau souhaite  restaurer  l'ecran,  il  envoie  un  signal
  SIGQUIT  au  processus  /sbin/screenblanker.   Votre  script  ou votre
  economiseur d'ecran devrait le  capturer  et  se  terminer.  Pensez  a
  restaurer l'ecran au mode texte initial.

  1122..  PPrroobblleemmeess ccoouurraannttss eett qquueessttiioonnss ddiivveerrsseess

  1122..11..   PPoouurrqquuooii jj''oobbttiieennss lleess mmeessssaaggeess ""CCaannnnoott llooccaattee mmoodduullee ffoorr nneett--
  ppff--XX"" lloorrssqquuee jjee llaannccee iiffccoonnffiigg

  Le  code  reseau a ete modifie vers les versions 1.3.80 du noyau, pour
  permettre le chargement de familles de protocole reseau  (par  exemple
  IPX,  AX.25  et  AppleTalk) sous la forme de modules.  Cela a provoque
  l'ajout de certaines requetes kerneld : net-pf-X, ou _X est  un  numero
  identifiant       le       protocole       (voir       le      fichier
  _/_u_s_r_/_s_r_c_/_l_i_n_u_x_/_i_n_c_l_u_d_e_/_l_i_n_u_x_/_s_o_c_k_e_t_._h pour la liste de  ces  nombres).
  Malheureusement,  ifconfig provoque l'envoie de ces messages, donc bon
  nombre de personnes recoivent ces messages lors de l'amorcage de  leur
  machine   et   lorsqu'ils   lancent   ifconfig   pour  configurer  les
  peripheriques loopback.  Ces messages sont uniquement  informatifs  et
  ne  cassent  rien.  Vous  pouvez  les  retirer  en ajoutant les lignes
  suivantes :

          alias net-pf-3 off      # oublier AX.25
          alias net-pf-4 off      # oublier IPX
          alias net-pf-5 off      # oublier AppleTalk

  au fichier /etc/conf.modules. Bien sur, si  vous  utilisez  IPX  comme
  module, n'ajoutez pas la ligne pour desactiver IPX.

  1122..22..  MMaa mmaacchhiinnee rraalleennttiitt !!

  Apres  avoir  lance  kerneld,  mon systeme commence a ralentir lorsque
  j'active ma connexion PPP.

  Il y a eu un certain nombre de messages a ce sujet. Il semble qu'il  y
  a  une  interaction  malheureuse  entre kerneld et le script tkPPP qui
  utilise  sur  certains  systeme  pour  configurer  et  surveiller   la
  connexion  PPP.  Le  script semble boucler lorsqu'il execute ifconfig.
  kerneld, pour rechercher les modules net-pf-X (voir plus haut dans  ce
  document),  charge  un  peu  la  machine  et  il est possible que vous
  obteniez quelques messages Cannot locate module for net-pf-X.  Il  n'y
  a pas actuellement de solution, si ce n'est de ne plus utiliser tkPPP,
  ou de le modifier pour  qu'il  change  sa  maniere  de  surveiller  la
  connexion.

  1122..33..  kkeerrnneelldd nnee cchhaarrggee ppaass mmoonn ggeessttiioonnnnaaiirree ddee ppeerriipphheerriiqquuee SSCCSSII !!

  Ajoutez  une   entree   pour   la   carte   SCSI   dans   le   fichier
  /etc/conf.modules. Lisez la partie decrivant l'entree scsi_hostadapter
  dans ce document.

  1122..44..  mmooddpprroobbee ssee ppllaaiinntt qquuee ggcccc22__ccoommppiilleedd n'est pas definit

  C'est  une  erreur  dans  les utilitaires des modules qui ne se revele
  qu'avec  le  paquetage  binutils2.6.0.9  ou  plus  ancien,  et   c'est
  documente  dans  les notes de mises a jour du paquetage binutils, donc
  lisez-la, ou bien mettez a jour le paquetage des modules  qui  corrige
  ce probleme.

  1122..55..   MMoonn ggeessttiioonnnnaaiirree ddee ccaarrttee ssoonn ccoonnttiinnuuee aa nnee ppaass iinniittiiaalliisseerr llee
  vvoolluummee,, eettcc

  Les  configurations d'un modules sont stockees dans le module lui-meme
  lorsqu'il est charge. Donc lorsque kerneld decharge automatiquement un
  module,   toute  configuration  particuliere  disparait,  et  lors  du
  prochain chargement,  c'est  la  configuration  par  defaut  qui  sera
  appliquee.

  Vous  pouvez  specifier a kerneld de configurer un module en executant
  un programme apres le  chargement  du  module.  Consultez  la  section
  traitant l'entree post-install.

  1122..66..   DDOOSSEEMMUU aa bbeessooiinn ddee cceerrttaaiinnss mmoodduulleess -- ccoommmmeenntt kkeerrnneelldd ppeeuutt lleess
  cchhaarrggeerr ??

  Vous  ne  pouvez  pas. Aucune des versions de dosemu (que cela soit la
  version officielle ou de developpement)  ne  gere  le  chargement  des
  modules _v_i_a kerneld.  Toutefois, si vous utilisez les noyaux 2.0.26 ou
  superieur, vous n'avez pas  besoin  de  modules  dosemu  particuliers?
  Installez tout simplement, la version dosemu 0.66.1, ou superieure.

  1122..77..   PPoouurrqquuooii jj''oobbttiieennss ddeess mmeessssaaggeess ""OOuucchh,, kkeerrnneelldd ttiimmeedd oouutt,, mmeess--
  ssaaggee ffaaiilleedd"" ??

  Lorsque  le  noyau  envoie une requete au demon kerneld, il s'attend a
  recevoir un acquittement dans la seconde qui suit. Si kerneld  ne  lui
  renvoie pas cet acquittement, alors ce message est diffuse. La requete
  est alors reemise.

  Cela arrive sur des systemes tres fortement charges, comme kerneld est
  un  processus  en  mode utilisateur, il est ordonnance comme n'importe
  quel autre processus du systeme.  Si  la  charge  de  la  machine  est
  importante,  il  ne  sera pas en execute avant que le timeout du noyau
  intervienne.

  Si cela se produit lorsque la charge est faible, essayez  de  relancer
  kerneld   (tuez   le  processus  est  relancez  le  avec  la  commande
  /usr/sbin/kerneld).  Si le probleme persiste, vous devriez envoyer  un
  courrier  electronique  dans  la  liste linux-kernel@vger.rutgers.edu,
  mais assurez-vous que les versions du noyau et de kerneld sont a  jour
  avant de diffuser un message relatant un tel probleme.

  1122..88..  mmoouunntt nn''aatttteenndd ppaass qquuee llee ssyysstteemmee ddee ffiicchhiieerr ssooiitt cchhaarrggee

  Il y a certains rapports comme quoi la commande mount(8) n'attend  pas
  que  kerneld  charge  le  module  du  systeme  de fichiers, et si vous
  repetez  l'operation  immediatement  apres,  cela  fonctionnera.  Cela
  semble  etre  une  erreur  dans  les  utilitaires  des modules version
  1.3.69f qui affecte certains utilisateurs de distribution Debian -  il
  peut   etre   corrige  en  recuperant  en  version  plus  recente  des
  utilitaires.

  1122..99..  kkeerrnneelldd nn''aarrrriivvee ppaass aa cchhaarrggee llee mmoodduullee nnccppffss

  Vous devez compiler les outils  ncpfs  avec  l'option  -DHAVE_KERNELD.
  Regardez le fichier Makefile de ncpfs.

  1122..1100..  kkeerrnneelldd nn''aarrrriivvee ppaass aa cchhaarrggeerr llee mmoodduullee ssmmbbffss

  Vous  utilisez une vieille version de smbmount.  Recuperez la derniere
  version          (0.10          ou           superieure)           sur
  ftp://tsx-11.mit.edu/pub/linux/filesystems/smbfs/.

  1122..1111..  JJ''aaii ttoouutt ccoommppiillee ssoouuss ffoorrmmee ddee mmoodduullee,, eett mmaaiinntteennaanntt mmoonn ssyyss--
  tteemmee nn''aarrrriivvee pplluuss aa cchhaarrggeerr llee mmoodduullee dduu ssyysstteemmee ddee ffiicchhiieerrss rraacciinnee

  Vous ne pouvez pas tout transformer en modules : le noyau  doit  avoir
  assez  de  gestionnaires  pour  etre  capable  de monter sa racine, et
  executer certains programmes pour lancer kerneld. Donc, vous ne pouvez
  pas modulariser :

  +o  le gestionnaire pour le disque dur ou se trouve votre racine ;

  +o  le systeme de fichiers de votre racine ;

  +o  le format des binaires pour les programmes init, kerneld, ...

  En  fait,  cela n'est vrai qu'a moitie. Les derniers versions du noyau
  1.3.x   et   2.x   permettent   l'utilisation   d'une    ram    disque
  d'initialisation  qui  est chargee par LILO ou LOADLIN, et donc il est
  possible de charger le module du systeme de fichiers de la racine sous
  cette  forme. Consultez le fichier _D_o_c_u_m_e_n_t_a_t_i_o_n_/_i_n_i_t_r_d_._t_x_t situe dans
  les sources du noyau pour plus d'informations !

  1122..1122..  lliibbggddbbmm kkeerrnneelldd nnee ssee llaannccee  ppaass  lloorrss  ddee  ll''aammoorrccaaggee  ddee  llaa
  mmaacchhiinnee -- iill ddeemmaannddee

  Les nouvelles versions de kerneld ont besoin de  la  bibliotheque  GNU
  dbm  pour s'executer, libgdbm.so. Bon nombre d'installations ont cette
  bibliotheque installee dans le repertoire  /usr/lib,  mais  vous  avez
  probablement  lance  kerneld avant que le systeme de fichier monte sur
  le repertoire /usr ne soit monte. Un symptome de  cette  configuration
  est  que kerneld ne se lancera pas lors de l'amorcage de la machine (a
  partir de vos fichiers rc), mais  tournera  parfaitement  si  vous  le
  lancez  a  la  main.  La  solution et de soit deplacer le lancement de
  kerneld apres que /usr soit monte, soit de  deplacer  la  bibliotheque
  dans  le  systeme  de  fichiers  racine,  comme  par  exemple  dans le
  repertoire /lib.

  1122..1133..  JJee rreeccooiiss llee mmeessssaaggee ""CCaannnnoott llooaadd mmoodduullee xxxxxx"" mmaaiiss jj''aaii  ppoouurr--
  ttaanntt rreeccoonnffiigguurree mmoonn nnooyyaauu ssaannss llaa ggeessttiioonn xxxxxx

  L'installation   de   la   Slackware   (et   eventuellement   d'autres
  distributions)  cree  un  fichier  /etc/rc.d/rc.modules par defaut qui
  effectue une modprobe explicite sur un certain nombre de modules.  Les
  modules  qui  sont  parcourus  dependent  du  noyau initial. Vous avez
  surement reconfigure votre noyau pour exclure un certain nombre de ces
  modules,   d'ou  le  message  d'erreur.   Mettez  a  jour  le  fichier
  rc.modules en mettant  en  commentaires  tous  les  modules  que  vous
  n'utilisez  plus.  Une autre solution consiste a supprimier le fichier
  rc.modules et a laisser kerneld charger les modules lorsqu'il le  juge
  necessaire.

  1122..1144..  ttoouujjoouurrss ddeess mmeessssaaggeess ccoonncceerrnnaanntt ddeess ssyymmbboolleess nnoonn rreessoolluuss JJ''aaii
  rreeccoommppiillee mmoonn nnooyyaauu eett lleess mmoodduulleess mmaaiiss jj''oobbttiieennss

  Vous   avez  surement  reconfigure/recompile  votre  noyau  et  exclus
  certains modules. Vous possedez  certains  anciens  modules  que  vous
  n'utilisez  plus  mais  qui  se  trouvent  toujours dans le repertoire
  /lib/modules. La solution  la  plus  simple  conssite  a  detruire  le
  repertoire  /lib/modules/x.y.z  et a effectuer un make modules_install
  depuis les sources du noyau. Il est utile de preciser que ce  probleme
  n'intervient que lorsque vous reconfigurez votre noyau sans changer de
  version?  Si vous voyez cette erreur lors d'un passage a une  nouvelle
  version c'est qu'il y a un autre probleme.

  1122..1155..  JJ''aaii iinnssttaallllee LLiinnuuxx 22..11,, eett aauuccuunn mmoodduullee nnee ssee cchhaarrggee

  Linux 2.1 est le noyau actuellement en  cours  de  developpement.   En
  tant  que  tel, il faut s'attendre a ce que des problemes se posent de
  temps en temps. Une des grandes modifications de la version 2.1 est la
  gestion des modules ainsi que l'endroit ou les modules sont charges en
  memoire.  De  plus,  Richard  Henderson  est   desormais   charge   du
  developpement des modules dans le noyau.

  En  resume,  si vous souhaitez utiliser les modules avec un noyau 2.1,
  vous devez :

  +o  lire le fichier Documentation/Changes et voir quels paquetage  vous
     devez mettre a jour sur votre systeme ;

  +o  utiliser  le dernier paquetage modutils que l'on peut recuperer sur
     les sites :

     ftp://ftp.redhat.com/pub/alphabits/
     ftp://tsx-11.mit.edu/pub/linux/packages/alphabits/

  Il est egalement recommande d'utiliser un noyau 2.1.29 ou superieur si
  vous souhaitez utiliser les modules.

  1133..  CCooppyyrriigghhtt

  Ce document est copyrighte (c) Henrik Storner, 1996, 1997

  Sauf contre-ordre, les documents HowTo pour Linux sont copyrightes par
  leurs auteurs respectifs. Ces  documents  peuvent  etre  reproduit  et
  distribues dans leur ensemble ou en partie, sur n'importe quel type de
  support physique ou electronique, du moment ou cette notice legale  se
  trouve  sur  toutes  les copies. Les redistributions commerciales sont
  autorisees et encouragees. Toutefois, l'auteur aimerai bien etre avise
  de toute distribution de ce genre.

  Toute  traduction,  travail  derive ou complementaire incluant tout ou
  partie de document HowTo Linux doit etre couvert par ce copyright.  De
  cette  maniere,  vous  ne pouvez creer un document qui s'inspire de ce
  document et imposer des restrictions supplementaires sur sa diffusion.
  Des  exceptions  a  ces conditions peuvent etre donnees sous certaines
  conditions.  Contactez le coordonnateur des HowTo  Linux  a  l'adresse
  donnee un peu plus bas.

  En resume, nous souhaitons promouvoir la diffusion de ces informations
  a travers le  maximum  de  moyen  de  communication.  Toutefois,  nous
  souhaitons  conserver  un  copyright  sur  les documents HowTo et nous
  souhaitons etre avertis de leur redistribution.

  Si vous avez des questions, vous pouvez  contacter  Greg  Hankins,  le
  coordonnateur   des   HowTo   Linux   par   courrier   electronique  :
  gregh@sunsite.unc.edu.

