[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Prob Compil noyo



Le Sat, Jul 06, 2002 at 12:51:43AM +0100, Yves Rutschle ecrit :
> On Sat, Jul 06, 2002 at 01:17:02AM +0200, Francois Cerbelle wrote:
> [Interêt de initrd]
> > Tout simple, si tu as un parc de machines dont la configuration est *A
> > PEU PRES* la même, mais pas exactement : une avec une carte graphique
> > ATI, l'autre avec Matrox, .... Mais toutes doivent avoir le support NFS
> > (pour les repertoires home) par exemple ==>
> > Kernel avec :
> > - en dur : NFS
> > - en mou (initrd) : ATI, Matrox
> > 
> > Et tu deploies ton joli kernel dans le même joli paquet .deb sur toutes
> > les jolies machines !!! :-)
> Mais mais mais (mais j'ai déjà dis ça ce soir), tu peux
> aussi faire ça sans initrd:
> - en dur NFS
> - en module dans le /lib/modules normal, ATI, Matrox
> et quand le noyau boote, il charge ce qu'il faut. C'est
> comme ça que la plupart des distributions font du
> "plug-and-play" (en quelque sorte: on met le périphérique et
> le driver est déjà là).
> A priori, ça ne devrait être utile que pour charger la vraie
> root, ce qui implique que les machines de ton parc ont
> toutes des roots différentes:
> - Une en ext2 sur hda2
> - Une en reiserfs sur sda4
> - Une en nfsroot
> Ce qui permet au même (petit) noyau de démarrer, charger
> soit ide/ext2, soit reiserfs/scsi soit nfs, sans que ça soit
> imposé en dur pour les autres machines.
> Mais mais mais, ça pourrait tout être compilé en __init dans
> le noyau, et faire un noyau qui supporte, seulement au
> démarrage, ext2, reiserfs, ide et scsi et nfsroot, puis
> "oublie" tout ça.
> Mais ça implique pas mal de retouches dans le code, et en
> plus ça rend le noyau (le vrai, celui qui a besoin d'être en
> mode superviseur) plus gros pour rien, d'où la volonté de
> pousser l'initialisation dans l'userland, d'où initrd tout
> le temps.
> Tiens, maintenant j'ai compris :-)
> > Y'a pas de raison, ce sont des vases communiquants : Ce que tu ne mets
> > pas dans ton kernel, tu le mets dans le initrd, et vice versa, mais rien
> > ne t'oblige à en mettre plus que tu n'en as besoin. Au lieu d'avoir un
> > kernel monolithique de 700K, tu auras un kernel de 300K (taille
> > approximative d'un kernel sans drivers) et un initrd de 400K.
> N'y a-t-il pas besoin d'applications et donc de librairies
> dans le initrd?
Non, mais si tu regardes bien, lors du démarrage d'un kernel debian, par
exemple, tu as 5 secondes d'attente au boot, pendant lesquelles tu peux
lancer un shell. C'est dans le initrd que ca se passe, juste avant le
montage de /
initrd peut contenir un fichier linuxrc à lancer pour executer des
commandes. Par exemple, un script qui va detecter que ta racine est sur
/dev/sda4 plutot que /dev/hda1.
Ca te permet surtout d'avoir une seule compilation qui est generale,
mais qui sait s'adapter a tes configs sans recompil ni repackaging.
Le souci est que seul le FS ne suffit pas, il faut aussi les drivers
plus bas niveau comme pour moi, le driver IDE Promise RAID, les drivers
RAID, les drivers SCSI, les correctifs de ROM, ..... et oui, on n'y
pense pas forcement, mais y'en a besoin. Si tu arrives à tout desactiver
dans la config de ton kernel et à ne reactiver que et uniquement que ce
dont tu as besoin du premier coup de "make menuconfig", moi, la, je te
dis "chapeau". A chaque fois il me manque un petit bidule de rien : le
promise pour mon disque n'est qu'un exemple.

En plus, tu n'est pas du tout oblige de mettre TOUS les modules que tu
as compile dans le initrd, juste les modules necessaires entre le boot
et le montage de '/'

Je crois que l'on commence a etre un peu hors-sujet sur la ML.
-- 
(0> Francois Cerbelle            <O)              |\      _,,,---,,_
//\ mailto:francois@cerbelle.net /\\        ZZZzz /,`.-'`'    -.  ;-;;,_
V_/ Cell: (+33/0) 603 015 512    \_V             |,4-  ) )-,_. ,\ (  `'-'
#define QUESTION ((bb) || !(bb)) - Shakespeare  '---''(_/--'  `-'\_)


-- 
To UNSUBSCRIBE, email to debian-user-french-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: