laisser en modules ?

Quand tu recompiles le noyau, tu choisis aussi ce que tu veux mettre en modules, et tu les compiles à ce moment là-aussi.

Jak a écrit a écrit : Quand tu recompiles le noyau, tu choisis aussi ce que tu veux mettre en modules, et tu les compiles à ce moment là-aussi.

 
hein ? excuses moi, mais j'ai pas compris là.
j'entends dire (ce que j'a p-t mal compris) que les modules peuvent être mis en dur dans le noyau par recompilation : ça a quel interet ?

vi tu peux les mettre en "durs" dans le noyaux.
 
l'intérêt... y avoir accès sans devoir les charger (c auto en général)...
non je sais pas trop
 
sinon l'intérêt de recompiler est d'avoir un kernel fait sur mesure pour ton pc.  Pas besoin d'avoir une gestion du scsi si tu n'as pas de périphériques scsi, etc...
D'ou un démarrage de la machine plus rapide entre autre.

ethernal a écrit a écrit : vi tu peux les mettre en "durs" dans le noyaux.   l'intérêt... y avoir accès sans devoir les charger (c auto en général)... non je sais pas trop   sinon l'intérêt de recompiler est d'avoir un kernel fait sur mesure pour ton pc.  Pas besoin d'avoir une gestion du scsi si tu n'as pas de périphériques scsi, etc... D'ou un démarrage de la machine plus rapide entre autre.

 
 
l'interet d'avoir un noyau sur mesure je connais
mais l'interet d'avoir ces drivers en dur dans le kernel plutot qu'en module, c'est ça que je connais pas

 
Pour pouvoir les avoir même si il n'y a pas d'accès disque. Par exemple, il faut le controleur du disque sur lequel est /, le type de FS de /, l'ACPI si on veut que le shutdown fasse poweroff.
 
On peut faire pire : mettre tout netfilter en dur dans le noyau (sans module), ce qui fait que si on fait un shutdown, alors qu'il y a écrit "the system is halted", le routage/filtrage marche encore

 
 
ok merci
ça commence a devenir clair  

+ cela peut éviter de faire un initrd pour charger les modules au démarrage ( genre la gestion de ton controleur, le sys de fichier de /boot ou / ).
 
+ c'est un peu plus rapide ( je crois que l'on gagne 5% en rapidité, mais bon cela n'a jamais été mesuré )
 
+ ... par contre le noyau est plus gros

ben tiens, je viens de tomber sur un exemple concret où vous allez pouvoir m'aider :
je suis en train de lire le howto de rusty sur le filtering avec le kernel 2.4
pour effectuer du filtering, il dit qu'il faut insérer les modules de suivi de connection (ip_countrack ...)
à votre avis, ça a un interet de les mettre dans le noyau, ou les laisser en modules est aussi bien ?

[jfdsdjhfuetppo]--Message édité par djoh--[/jfdsdjhfuetppo]

 
Ils sont très bien en module. Seul les psychopates les mettent dans le noyau.

Ah j'oubliais, le noyau a une taille maxi à ne pas dépasser, donc a force de mettre tout dedans, on atteint facilement la taille limite.

 
1- ben en contre partie, si on enleve tous les trucs qui nous servent à rien (pcmcia entre autres ...), il doit rester de la marge , non ?
 
2- elle est de combien, la taille max ?
 
3- j'ai pas recompiler mon noyau, donc il doit rester de la place dedans    
 
enfin, si c'est pas utile, je le ferais pas, c'est juste a titre d'information, toutes ces questions  

[jfdsdjhfuetppo]--Message édité par djoh--[/jfdsdjhfuetppo]

1- ben en contre partie, si on enleve tous les trucs qui nous servent à rien (pcmcia entre autres ...), il doit rester de la marge , non ?
 
Cette fameuse (fumeuse?) taille limite n'est pas due au kernel en lui-même, mais au loader (le truc appelé par lilo, le main du kernel en quelque sorte). Donc si quelque chose est en module ou pas du tout dans le kernel, ça ne change rien, c'est pour ça que les distribution, tout les modules sont compilés.
 
2- elle est de combien, la taille max ?
 
Ca dépend du loader. Il y en a deux si ma mémoire est bonne (z et bz). Pour le premier loader (celui mis lorsque l'on fait un make zImage), c'est 576ko (maximum mode réel moins le premier segment => 640Ko-64Ko).
 
Le second (make bzImage) est mieux foutu, il a une taille limite de 15Mo, mais il tricote toujours avec les limitations du 8086
 
Un post tiré de LKML sur le sujet :  
http://www.uwsg.iu.edu/hypermail/l [...] /0844.html

kadreg a écrit a écrit : 1- ben en contre partie, si on enleve tous les trucs qui nous servent à rien (pcmcia entre autres ...), il doit rester de la marge , non ?   Cette fameuse (fumeuse?) taille limite n'est pas due au kernel en lui-même, mais au loader (le truc appelé par lilo, le main du kernel en quelque sorte). Donc si quelque chose est en module ou pas du tout dans le kernel, ça ne change rien, c'est pour ça que les distribution, tout les modules sont compilés.   2- elle est de combien, la taille max ?   Ca dépend du loader. Il y en a deux si ma mémoire est bonne (z et bz). Pour le premier loader (celui mis lorsque l'on fait un make zImage), c'est 576ko (maximum mode réel moins le premier segment => 640Ko-64Ko).   Le second (make bzImage) est mieux foutu, il a une taille limite de 15Mo, mais il tricote toujours avec les limitations du 8086   Un post tiré de LKML sur le sujet :   http://www.uwsg.iu.edu/hypermail/l [...] /0844.html

 
ben moi, je sais pas lequel j'ai vu que j'ai pas compiler (kernel installé par packages), donc j'ai pas fait de (b)zimage.
 
mais je croyais que la taille autoriser était plus élever que ça ...
 
comment on voit la taile de son kernel ?

ben moi, je sais pas lequel j'ai vu que j'ai pas compiler (kernel installé par packages), donc j'ai pas fait de (b)zimage.
 
C'est bz qui est utilisé. Le zImage n'a normalement plus à servir.
 
mais je croyais que la taille autoriser était plus élever que ça ...
 
Bah non. Enfin 15Mo pour les remplir, il faut déjà y mettre du coeur.
 
 
comment on voit la taile de son kernel ?
 
tu regardes la taille de ton fichier vmlinuz (celui défini par lilo).
 
Par exemple, chez moi :  

 
 
ah ouai, moi je dois cofondre avec la taille avec tous les modules en plus
 
pour le vmlinuz, c'est bien ce qu'il me semblait, mais il a une taille ridicule, je pensais que c'était bcp plus gros que ça moi    
 
quand tu fais un ls -l, c'est bien en octets qu'est indiquer la taille, non ?
 
et j'ai deux noyau, celui d'origine (2.2), et celui que j'ai installer par apt-get (2.4.17), ben le plus récent est plus petit !  
600 ko !  c'est rien du tout ça , didonc

ah ouai, moi je dois cofondre avec la taille avec tous les modules en plus
 
oui
 
quand tu fais un ls -l, c'est bien en octets qu'est indiquer la taille, non ?
 
Oui, c'est les modules qui sont gros (c'est des kilo-octets) :  
 

 
 
600 ko !  c'est rien du tout ça , didonc
Avec tout en module, il y a plus grand chose à garder dedans.

 
 
ben, les pilote par défaut doivent être dedans
la gestion de la memoire, la gestion de la fs, netfilter ...
dois y avoir encore autre chose, ça en fait quand meme ...
enfin bon, tant mieux, tout va bien alors  

et merci pour le "du", je connaissais pas  

je viens de verifier, et je confondais bien la taille avec et sans module puisque ça correspond a la taille qu'il me semblait que faisait mon kernel :
ancien (2.2) : 1Mo + 12 Mo
nouveau (2.4) : 600 Ko + 25 Mo
 
et aux niveau des modules, j'ai rien de trop qu'est lancé (lsmod je crois), donc tout vas bien  

moi j'ai mieux :
> ls -sh
 
[root@bastard i386-linux]# ls -sh /boot/vmlinuz*
   0 /boot/vmlinuz@              1.1M /boot/vmlinuz-2.4.17-10mdk
1.1M /boot/vmlinuz-2.4.13-10mdk  865K /boot/vmlinuz-2.4.17-13mdk
1.1M /boot/vmlinuz-2.4.13-12mdk  865K /boot/vmlinuz-2.4.17-14mdk
1.1M /boot/vmlinuz-2.4.13-6mdk   866K /boot/vmlinuz-2.4.17-15mdk
1.1M /boot/vmlinuz-2.4.16-10mdk  866K /boot/vmlinuz-2.4.17-16mdk
1.1M /boot/vmlinuz-2.4.16-4mdk   1.1M /boot/vmlinuz-2.4.17-7mdk
1.1M /boot/vmlinuz-2.4.16-9mdk
 
 
il rajoute les unitées, pas besoin de se casser la tête