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.