On 9 Apr 2002, Filipe Bonjour wrote:
> du kernel. Puis un jour j'ai lu quelque part (et perdu la reference,
> helas) qu'avant de configurer le kernel (avec make menuconfig, p. ex.)
> il fallait s'assurer que les repertoires /usr/include/asm,
> /usr/include/linux et /usr/include/scci devraient en fait etre des liens
En fait, la méthode de compilation du kernel a évolué.
Aujourd'hui, on se base sur l'hypothèse que la machine qui va tourner un
kernel donné n'est _pas forcément_ celle qui a compilé ce kernel: et la
machine de génération ne tourne même pas forcément la même version majeure
du kernel. Il n'est même pas garanti que la machine cible possède les
outils nécessaires à la génération d'un kernel (packages de développement
de la libc, outils binutils, compilateur, includes, sources du kernel).
Pour cette raison, on se base sur les hypothèses suivantes:
- on peut avoir envie de générer un kernel pour une machine cible
différente sans avoir besoin de droits root.
- on peut avoir envie de générer un kernel pour des sous-systèmes
(Debian les appelle modules) en relation avec un kernel.
sous-systèmes: p.ex. le sous-système PCMCIA avec un kernel 2.2.x
en conséquence, mettre le kernel dans /usr/src n'est plus une bonne
solution par défaut. Avoir besoin de modifier /usr/include/linux ou
/usr/include/asm est encore moins une bonne chose.
La méthode choisie est alors la suivante:
- avoir sur la machine qui génère les kernels les outils de base
nécessaires
- décompacter sous un utilisateur normal le kernel source choisi, dans
un répertoire normal (p.ex. ~schaefer/KERNELS/linux-2.4.9/)
- configurer ce kernel (make menuconfig p.ex.)
- générer ce kernel, y compris les modules associés
- générer éventuellement un package binaire, installable sur la
machine cible.
- on ne touche pas /usr/include/linux, /usr/include/asm et encore
moins /usr/src: /usr/include/linux et /usr/include/asm doivent
correspondre, en fait, à la version de la *libc* installée: celle-ci
s'arrange pour la compatibilité avec différentes versions majeures
des kernels. Bien souvent aujourd'hui, ces fichiers sont livrés
avec la libc:
schaefer@defian:~% dpkg -S /usr/include/linux/version.h
libc6-dev: /usr/include/linux/version.h
Qu'en est-il des sous-systèmes ? Ceux-ci ne devraient, dans l'idéal,
jamais dépendre d'un kernel source à un endroit précis, mais au contraire
donner la possibilité à l'utilisateur qui les génère de donner ces
informations. Cela est également valable pour les modules propriétaires ou
libres qui ne sont pas livrés avec le kernel. Prenons l'exemple du pilote
3Com 3c90x, qui supporte certains chips utilisés dans le matériel Dell
mieux que le pilote 3c59x standard du kernel, et qui est GPL: dans ce cas
il suffit d'éditer le script de compilation et de mettre la bonne option
-I, comme par exemple ~/KERNELS/linux-2.2.18m/include/.
Maintenant qu'en est-il de l'implémentation ? Comme toujours, il y a des
différences entre les distributions: mais apparemment, au moins depuis la
libc6 (glibc 2.x), il semble y avoir une convergence compatible avec ce
qui précède.
Le cas de la distribution Debian stable:
- il est recommandé d'utiliser le package kernel-package qui permet
de recompiler ses propres kernels en suivant à peu près ce qui
précède
- on peut compiler, avec kernel-package, où l'on veut et sous
l'utilisateur que l'on veut (via fakeroot), sans modifier le système.
- on peut facilement générer des packages binaires kernel, comprenant
kernel, modules du kernel, configuration et System.map, et supportant
la modification automatique de la configuration du boot-loader (p.ex.
LILO) si l'on n'a pas modifié ce fichier manuellement. On peut
spécifier une version locale pour le package.
- kernel-package peut, si on le désire, être utilisé également avec
les packages sources Debian (kernel, sous-systèmes, patches appliqués
automatiquement à choix), mais ce n'est pas obligatoire: je
recommande l'utilisation de kernels `pristine' de kernel.org
- malheureusement, si l'on veut pouvoir utiliser kernel-package pour
également compiler des sous-systèmes (ce que Debian appelle des
modules: p.ex. PCMCIA), il faut installer ceux-ci dans
/usr/src/modules/: sinon la compilation n'est pas automatique. Cela
implique en règle générale une installation et une compilation sous
root, ce qui est dommage (*)
NB: dans ce qui précède, on n'a jamais traité le thème de la
cross-compilation (compilation croisée: p.ex. compiler un kernel SPARC
sous ix86). A mon avis cela viendra un jour également.
(*) je n'ai pas creusé pour voir si l'on peut respecter les hypothèses de
base également dans le cas de sous-systèmes, vu que mon système de
préparation de kernels est justement mon portable et que les autres n'ont
pas besoin du sous-système PCMCIA.
Il y avait un article de Linus expliquant cela mais je ne l'ai plus
retrouvé, à vos search engines :9
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se désabonner aussi.
