Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
3479 connectés 

  FORUM HardWare.fr
  Linux et OS Alternatifs

  Qu'est ce que ça apporte de recompiler le noyau plutot que de ....

 
 


Dernière réponse
Sujet : Qu'est ce que ça apporte de recompiler le noyau plutot que de ....
Dark_Schneider 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

Votre réponse
Nom d'utilisateur    Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !
Le ton de votre message                        
                       
Votre réponse
[b][i][u][strike][spoiler][fixed][cpp][url][email][img][*]   
 
   [quote]
 
Options

 
Vous avez perdu votre mot de passe ?


Vue Rapide de la discussion
Dark_Schneider 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
djoh 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  ;)
djoh et merci pour le "du", je connaissais pas  :jap:
djoh

kadreg a écrit a écrit :

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) :  
 

Code :
  1. [kadreg@luggage]/usr/src/linux/Documentation$ du -sk /lib/modules/*   
  2. 12072   /lib/modules/2.4.16
  3. 26268   /lib/modules/2.4.7-10
  4. [kadreg@luggage]/usr/src/linux/Documentation$


 
 
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  :jap:

kadreg 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) :  
 

Code :
  1. [kadreg@luggage]/usr/src/linux/Documentation$ du -sk /lib/modules/*   
  2. 12072   /lib/modules/2.4.16
  3. 26268   /lib/modules/2.4.7-10
  4. [kadreg@luggage]/usr/src/linux/Documentation$


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

djoh

kadreg a écrit a écrit :

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 :  

Code :
  1. [kadreg@luggage]/usr/src/linux/Documentation$ ll /boot/vmlinuz-2.4.7-10
  2. -rw-r--r--    1 root     root       802068 sep  6 23:39 /boot/vmlinuz-2.4.7-10
  3. [kadreg@luggage]/usr/src/linux/Documentation$

 




 
 
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  :heink:  
 
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 ! :ouch:  
600 ko !  c'est rien du tout ça , didonc :??:

kadreg 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 :  

Code :
  1. [kadreg@luggage]/usr/src/linux/Documentation$ ll /boot/vmlinuz-2.4.7-10
  2. -rw-r--r--    1 root     root       802068 sep  6 23:39 /boot/vmlinuz-2.4.7-10
  3. [kadreg@luggage]/usr/src/linux/Documentation$
djoh

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 ?

kadreg 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
djoh

kadreg a écrit a écrit :

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  :D  
 
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]
kadreg 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.
kadreg

djoh a écrit a écrit :

 
à votre avis, ça a un interet de les mettre dans le noyau, ou les laisser en modules est aussi bien ?  




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

djoh 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]
Dark_Schneider + 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
djoh

kadreg a écrit a écrit :

 
 
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  :jap:

kadreg

djoh a écrit a écrit :

 
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

djoh

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

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

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 ?

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

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo

Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)