Attachment 29445 Details for Bug 48071 – 2.6-koutput.xml - Translated XML document

2.6-koutput.xml - Translated XML document

2.6-koutput.xml (text/plain), 23.20 KB, created by Olivier Fisette (RETIRED) on 2004-04-16 14:24:19 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Olivier Fisette (RETIRED)

Created: 2004-04-16 14:24:19 UTC

Size: 23.20 KB

patch

obsolete

><?xml version='1.0' encoding="UTF-8"?>
>
><!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
>
><guide link="/doc/fr/2.6-koutput.xml" lang="fr">
>
><title>Les fichiers de sortie des noyaux 2.6</title>
>
><author title="DÃ©veloppeur">
>  <mail link="latexer@gentoo.org">Peter Johanson</mail>
></author>
><author title="Correcteur">
>  <mail link="bennyc@gentoo.org">Benny Chuang</mail>
></author>
><author title="Traducteur">
>  <mail link="olivier.fisette@sympatico.ca">Olivier Fisette</mail>
></author>
>
><abstract>
>Ce guide est destinÃ© aux dÃ©veloppeurs et couvre en dÃ©tails les rÃ©cents
>changements relatifs aux fichiers de sortie des noyaux dans Gentoo.
></abstract>
>
><license/>
>
><version>1.2</version>
><date>26 mars 2004</date>
>
><chapter>
><title>PrÃ©face</title>
><section>
><title>Le nouveau systÃ¨me</title>
><body>
>
><p>
>Parmi la myriade d'amÃ©liorations apportÃ©es au noyau Linux dans la sÃ©rie 2.6,
>une nouvelle infrastructure nommÃ©e Â«&nbsp;kbuild&nbsp;Â» a Ã©tÃ© dÃ©veloppÃ©e afin
>de fournir un systÃ¨me de compilation hautement configurable et versatile. La
>portÃ©e de ce changement ne sera pas Ã©tudiÃ©e dans le prÃ©sent document&nbsp;;
>nous nous intÃ©resserons plutÃ´t Ã  la nouvelle mÃ©thode recommandÃ©e pour la
>compilation de modules externes contre l'arbre des sources d'un noyau 2.6.
>Voici une traduction libre d'un extrait de
><path>Documentation/kbuild/modules.txt</path>&nbsp;:
></p>
>
><pre caption="Documentation/kbuild/modules.txt">
>Compiler des modules hors du noyau officiel
>-------------------------------------------
>Des modules sont frÃ©quemment dÃ©veloppÃ©s hors du noyau officiel. Afin d'Ãªtre Ã 
>jour relativement aux changements apportÃ©s au systÃ¨me de compilation, la maniÃ¨re
>la plus transposable d'un systÃ¨me Ã  un autre pour compiler un module hors du
>noyau est d'utiliser la commande suivante&nbsp;:
>
>make -C chemin/vers/noyau/src SUBDIRS=$PWD modules
></pre>
>
><p>
>En Ã©crasant la variable SUBDIRS, la plus rÃ©cente architecture kbuild permet de
>compiler aisÃ©ment des modules externes. En soit, il s'agit d'une amÃ©lioration
><e>Ã©norme</e>, mais les choses deviennent problÃ©matiques lorsque l'on
>s'attarde aux dÃ©tails du procÃ©dÃ©.
></p>
>
></body>
></section>
><section>
><title>Le problÃ¨me</title>
><body>
>
><p>
>Ayant configurÃ© et compilÃ© un noyau de la sÃ©rie 2.6 dont les sources rÃ©sident
>dans <path>/usr/src/linux</path>, il n'est pas dÃ©raisonnable de supposer que je
>veuille ensuite compiler quelques modules externes contre l'arbre de ce noyau.
>De plus, on peut raisonnablement s'attendre Ã  ce que cela puisse Ãªtre fait par
>un utilisateur non-privilÃ©giÃ©. Pourtant, ceux qui ont essayÃ© savent que ce
><e>n'est pas</e> le cas. Une telle tentative se solde par un Ã©chec car
><c>make</c> tente de mettre Ã  jour des fichiers dans
><path>/usr/src/linux</path> alors que les utilisateurs non-privilÃ©giÃ©s n'ont pas
>accÃ¨s Ã  cet emplacement en mode Ã©criture.
></p>
>
><p>
>Les modules compilÃ©s par le systÃ¨me Portage ont exactement le mÃªme
>problÃ¨me&nbsp;: lorsqu'une mise Ã  jour est lancÃ©e, elle Ã©choue Ã  cause de
>violations de l'environnement bac Ã  sable. Le systÃ¨me kbuild a complexifiÃ© la
>compilation de modules de telle maniÃ¨re qu'il est difficile d'utiliser le
>principe sÃ©curitaire des privilÃ¨ges minimum. 
></p>
>
><p>
>Une recherche sur le systÃ¨me Bugzilla de Gentoo montre que beaucoup de bogues
>causÃ©s par ce problÃ¨me ont Ã©tÃ© rapportÃ©s. Aussi, beaucoup d'articles prÃ©sentant
>la dÃ©sactivation du bac Ã  sable comme seule solution ont Ã©tÃ© postÃ©s dans les
>forums. ConsidÃ©rant l'Ã©tat des choses Ã  ce moment, il semblait en effet
>inÃ©vitable d'avoir Ã  Ã©crire ou Ã  mettre Ã  jour des fichiers dans
><path>/usr/src/linux</path> lors de la compilation de modules des noyaux 2.6.
></p>
>
></body>
></section>
><section>
><title>Lutter contre le systÃ¨me</title>
><body>
>
><p>
>Plusieurs faÃ§ons de Â«&nbsp;hacker&nbsp;Â» le systÃ¨me kbuild afin de le
>contourner ont Ã©tÃ© proposÃ©es, dont une suggÃ©rant de lier symboliquement les
>Ã©lÃ©ments de <path>/usr/src/linux</path> dans un rÃ©pertoire temporaire.
>Ultimement, toutes les solutions menaient Ã  des problÃ¨mes de sÃ©curitÃ©, car
><path>/usr/src/linux</path> devait Ãªtre touchÃ© d'une faÃ§on ou d'une autre.
>Toutefois, priver les utilisateurs d'un chemin permettant une mise Ã  jour
>relativement facile n'est pas une option acceptable. C'est pourquoi le nouveau
>kmod.eclass peut confÃ©rer Ã  Portage l'accÃ¨s en mode Ã©criture Ã 
><path>/usr/src/linux</path> pour les noyaux 2.6 plus anciens. 
></p>
>
><p>
>Comme il s'agit d'un risque de sÃ©curitÃ© majeur, les utilisateurs sont forcÃ©s
>d'accepter cette option lors de sa premiÃ¨re utilisation, par le bias d'un
>nouvel outil&nbsp;: <b>config-kernel</b>. Les utilisateurs peuvent exÃ©cuter
>config-kernel une fois pour accepter l'option, puis ils ne recevront qu'un
>avertissement chaque fois que Portage compilera un module du noyau en utilisant
>cette fonctionnalitÃ©.
></p>
>
><pre caption="ExÃ©cuter config-kernel">
># <i>config-kernel --allow-writable yes</i>
></pre>
>
></body>
></section>
><section>
><title>Accepter le changement</title>
><body>
>
><p>
>Une solution plus appropriÃ©e a vu le jour lorsqu'il est devenu Ã©vident que
>lutter contre les nouvelles fonctionnalitÃ©s de kbuild ne causerait que des
>problÃ¨mes de plus en plus nombreux dans le futur. En fait, la solution rÃ©side
>dans la nouvelle capacitÃ© de kbuild d'envoyer tous ses fichiers de sortie dans
>un rÃ©pertoire sÃ©parÃ©. Garder l'arbre des sources complÃ¨tement propre et 
>permettre aux modules externes de compiler contre des sources propres tout en
>envoyant leurs fichiers de sortie dans un rÃ©pertoire temporaire est la clÃ©.
></p>
>
><p>
>Les dÃ©tails des interactions de tous ces Ã©lÃ©ments sont plutÃ´t complexes. La
>section suivante essaie de faciliter l'assimilation de ces concepts en les
>dÃ©composant en morceaux plus simples.
></p>
>
></body>
></section>
></chapter>
><chapter>
><title>Les fichiers de sortie du noyau</title>
><section>
><title>Les variables KBUILD_OUTPUT et O</title>
><body>
>
><p>
>kbuild fournit deux variables dictant oÃ¹ le noyau devrait placer ses fichiers
>de sortie.
></p>
>
><table>
><tr>
>  <th>Variable</th>
>  <th>Utilisation</th>
></tr>
><tr>
>  <ti>KBUILD_OUTPUT</ti>
>  <ti>
>    Cette variable peut Ãªtre dÃ©finie dans le <path>Makefile</path> de plus haut
>    niveau du noyau si vous voulez spÃ©cifier un rÃ©pertoire de sortie par dÃ©faut
>    diffÃ©rent de l'arbre des sources lui-mÃªme.
>  </ti>
></tr>
><tr>
>  <ti>O</ti>
>  <ti>
>    Cette variable devrait Ãªtre utilisÃ©e sur la ligne de commande pour Ã©craser
>    tout autre paramÃ¨tre et indiquer oÃ¹ les fichiers de sortie produits par la
>    commande actuelle devraient Ãªtre placÃ©s.
>  </ti>
></tr>
></table>
>
><p>
>La combinaison de ces deux variables est la clÃ© pour une utilisation adÃ©quate
>de kbuild et Portage pour installer des modules du noyau.
></p>
>
></body>
></section>
><section>
><title>Changements relatifs Ã  l'installation des noyaux</title>
><body>
>
><p>
>Pour utiliser les fonctionnalitÃ©s de redirection de la sortie du noyau, le
>nouveau <path>kernel-2.eclass</path>, Ã©crit par <mail
>link="johnm@gentoo.org">John Mylchreest</mail> a Ã©tÃ© corrigÃ© pour ajouter un
>chemin par dÃ©faut <c>KBUILD_OUTPUT</c> dans le makefile de plus haut niveau du
>noyau (<path>/usr/src/linux/Makefile</path>). Par dÃ©faut, ce chemin a la valeur
><path>/var/tmp/kernel-output/${KV}</path> puisque <path>/var/tmp</path> est un
>emplacement appropriÃ© pour les fichiers temporaires qui doivent Ãªtre prÃ©servÃ©s
>lors des redÃ©marrages. 
></p>
>
><p>
>Une fois que cette variable est paramÃ©trÃ©e, toutes les commandes make exÃ©cutÃ©es
>dans l'arbre des sources du noyau envoyent leurs fichiers de sortie dans ce
>nouveau rÃ©pertoire. Rien de plus n'est nÃ©cessaire de la part de l'utilisateur
>et le changement est essentiellement (voyez la section suivante pour les
>exceptions) transparent. Une fois un noyau installÃ©, l'utilisateur n'a qu'Ã 
>faire&nbsp;:
></p>
>
><pre caption="Configurer le noyau">
># <i>make menuconfig</i>
></pre>
>
><p>
>et ils pourront configurer leur noyau puis le compiler.
></p>
>
></body>
></section>
><section>
><title>Changements importants concernant les emplacements des fichiers</title>
><body>
>
><p>
>Comme tous les fichiers gÃ©nÃ©rÃ©s sont maintenant placÃ©s dans un rÃ©pertoire
>sÃ©parÃ©, quelques fichiers clÃ©s aboutiront dans un endroit inattendu pour
>l'usager. Plus particuliÃ¨rement, les <path>.config</path> et
><path>bzImage</path> de l'utilisateur ne seront plus dans
><path>/usr/src/linux</path> comme ils l'Ã©taient auparavant. <mail 
>link="latexer@gentoo.org">Peter Johanson</mail> a Ã©crit un nouveau guide du
>noyau 2.6 disponible <uri
>link="http://www.gentoo.org/doc/en/2.6-koutput-user.xml">ici</uri> et destinÃ©
>aux utilisateurs finaux. Il souligne les changements apportÃ©s Ã  kbuild et, en
>particulier, les nouveaux emplacements de ces fichiers.
></p>
>
></body>
></section>
></chapter>
><chapter>
><title>Ebuilds pour les modules externes</title>
><section>
><title>Approche gÃ©nÃ©rale</title>
><body>
>
><p>
>Maintenant que les noyaux gÃ©nÃ¨rent leurs fichiers dans un emplacement
>diffÃ©rent, Ã©crire des ebuilds adhÃ©rant Ã  ce nouveau systÃ¨me est l'Ã©tape
>suivante. Mettre Ã  jour les ebuilds pour qu'ils vÃ©rifient la prÃ©sence de
>certains fichiers et en-tÃªtes dans l'emplacement appropriÃ© et pour qu'ils
>utilisent la magie <path>Makefile</path> appropriÃ©e est le secret.
></p>
>
><p>
>L'idÃ©e gÃ©nÃ©rale est de corriger les <path>Makefiles</path> des paquets pour
>qu'ils utilisent, lors de la compilation contre des noyaux 2.6, la variable O
>afin de gÃ©nÃ©rer leurs fichiers dans un rÃ©pertoire temporaire Ã  l'intÃ©rieur de
>l'environnement bac Ã  sable. Il ne reste qu'Ã  ajouter quelques piÃ¨ces pour
>faire fonctionner le tout et obtenir un nouveau paquet pour un module externe
>qui s'intÃ©grera avec succÃ¨s.
></p>
>
><note>
>L'obtention d'un module utilisable et fonctionnel aprÃ¨s la compilation et
>l'installation n'est <e>pas</e> abordÃ©e dans ce document. Il s'agit d'un
>problÃ¨me totalement diffÃ©rent que les auteurs du module devraient gÃ©rer en
>amont.
></note>
>
><p>
>Des changements ont Ã©tÃ© apportÃ©s Ã  <path>kmod.eclass</path> pour inclure
>quelques variables et outils que les auteurs d'ebuilds peuvent utiliser pour
>implÃ©menter plus aisÃ©ment les changements requis dans les ebuilds.
></p>
>
></body>
></section>
><section>
><title>CritÃ¨res Ã  remplir pour les Makefiles</title>
><body>
>
><p>
>L'utilisation de koutput oblige les <path>Makefile</path> des paquets de
>modules du noyau Ã  remplir certains critÃ¨res. Plus particuliÃ¨rement, ils
>devront utiliser la variable kbuild <c>O</c> afin de gÃ©nÃ©rer leurs fichiers
>dans un sous-rÃ©pertoire donnÃ© de <c>WORKDIR</c>. Souvent, cela sera quelque
>chose de semblable Ã  <path>${S}/tmp</path>. Lorsque ce systÃ¨me est utilisÃ©, le
>rÃ©pertoire de sortie doit compter le <path>.config</path> du noyau parmi ses
>fichiers. La copie de ce fichier peut Ãªtre faite Ã  partir du makefile ou du
>ebuild, mais l'intÃ©grer au makefile de faÃ§on appropriÃ©e pourrait mener Ã  une
>correction en amont qui dÃ©chargerait les dÃ©veloppeurs Gentoo de ce travail.
></p>
>
></body>
></section>
><section>
><title>FonctionnalitÃ©s de kmod.eclass</title>
><body>
>
><p>
>Tous les ebuilds de modules du noyau devraient dÃ©sormais utiliser
><path>kmod.eclass</path>. Voici un aperÃ§u de son utilisation. La fonction
>kmod_src_unpack() s'occupe du dÃ©sarchivage, ainsi que du rÃ©glage de plusieurs
>variables extrÃ¨mement utiles qui pourront Ãªtre utilisÃ©es par la suite. Deux
>variables peuvent Ãªtre paramÃ©trÃ©es par le ebuild afin de contrÃ´ler les
>fonctionnalitÃ©s de kmod_src-unpack().
></p>
>
><table>
><tr>
>  <th>Variable</th>
>  <th>Utilisation</th>
></tr>
><tr>
>  <ti>KMOD_SOURCES</ti>
>  <ti>
>    Si cette variable est rÃ©glÃ©e, ces fichiers (habituellement des archives tar)
>    seront dÃ©sarchivÃ©s dans WORKDIR. Autrement, ${A} sera dÃ©sarchivÃ©.
>    Alternativement, la variable peut Ãªtre rÃ©glÃ©e Ã  Â«&nbsp;none&nbsp;Â» si un
>    ebuild doit prendre en charge lui-mÃªme le dÃ©sarchivage et autres processus.
>  </ti>
></tr>
><tr>
>  <ti>KMOD_KOUTPUT_PATCH</ti>
>  <ti>
>    Si KV_OUTPUT a une valeur diffÃ©rente de <path>/usr/src/linux</path> et que
>    la prÃ©sente variable est rÃ©glÃ©e, le correctif spÃ©cifiÃ© sera appliquÃ©, en
>    utilisant epatch dans <path>${S}</path>. Bien que cela puisse Ãªtre fait
>    manuellement, la prÃ©sente variable peut Ãªtre utile pour ne pas avoir Ã 
>    dÃ©finir src_unpack() dans un ebuild.
>  </ti>
></tr>
></table>
>
><p>
>La fonction kmod_src_unpack() s'applique Ã  dÃ©terminer comment le pilote Ã 
>compiler devrait Ãªtre gÃ©rÃ©. Elle supporte d'ailleurs trÃ¨s bien les deux
>mÃ©thodes de compilation pour versions 2.6. Si la nouvelle mÃ©thode employant
>koutput est dÃ©tectÃ©e, la fonction appliquera le correctif spÃ©cifiÃ© par
>KMOD_KOUTPUT_PATCH si celui-ci existe. AprÃ¨s que kmod_src_unpack() ait Ã©tÃ©
>appelÃ©e, une plÃ©thore de variables deviennent disponibles et peuvent Ãªtre
>utilisÃ©es par aprÃ¨s dans le ebuild.
></p>
>
><table>
><tr>
>  <th>Variable</th>
>  <th>Signification</th>
></tr>
><tr>
>  <ti>KV_OUTPUT</ti>
>  <ti>
>    Le chemin d'accÃ¨s absolu utilisÃ© par le noyau pour ses fichiers de sortie.
>    Pour les noyaux 2.4, cela sera toujours <path>/usr/src/linux</path>. Pour
>    les 2.6, cela devrait Ãªtre un rÃ©pertoire diffÃ©rent (sinon la compilation du
>    module Ã©chouera).
>  </ti>
></tr>
><tr>
>  <ti>KV_OJB</ti>
>  <ti>
>    L'extension pour les modules du noyau pour cette version du noyau. Cela
>    sera soit Â«&nbsp;ko&nbsp;Â», soit Â«&nbsp;o&nbsp;Â», dÃ©pendamment.
>  </ti>
></tr>
><tr>
>  <ti>KV_VERSION_FULL</ti>
>  <ti>La version complÃ¨te du noyau.</ti>
></tr>
><tr>
>  <ti>KV_MAJOR</ti>
>  <ti>Le numÃ©ro de version majeure du noyau.</ti>
></tr>
><tr>
>  <ti>KV_MINOR</ti>
>  <ti>Le numÃ©ro de version mineure du noyau.</ti>
></tr>
><tr>
>  <ti>KV_PATCH</ti>
>  <ti>Le numÃ©ro de correction du noyau.</ti>
></tr>
><tr>
>  <ti>KV_TYPE</ti>
>  <ti>Le type du noyau (par exemple&nbsp;: "-gentoo-r1" pour
>"2.4.23-gentoo-r1")</ti>
></tr>
></table>
>
><p>
>La valeur de KV_OUTPUT est le facteur qui, ultimement, dÃ©termine quelle
>configuration de noyau a Ã©tÃ© dÃ©tectÃ©e et quelle mÃ©thode de compilation sera
>utilisÃ©e. Voici un tableau montrant les trois diffÃ©rentes configurations du
>noyau possibles et la valeur assignÃ©e Ã  la variable aprÃ¨s l'appel de la
>fonction kmod_src_unpack().
></p>
>
><table>
><tr>
>  <ti></ti>
>  <th>KV_OUTPUT</th>
>  <th>Approche pour compiler les modules</th>
></tr>
><tr>
>  <th>Noyau 2.4</th>
>  <ti>/usr/src/linux</ti>
>  <ti>
>  Flexible. Certains makefiles utiliseront des instructions manuelles, d'autres
>  emploieront <b>make -C $(KV_BUILD)</b>. Les deux techniques sont faciles Ã 
>  utiliser avec les noyaux 2.4.
>  </ti>
></tr>
><tr>
>  <th>Noyau 2.6, sortie normale</th>
>  <ti>/usr/src/linux</ti>
>  <ti>
>  Il s'agit de la mÃ©thode traditionnelle. kmod.eclass gÃ¨re cette situation en
>  utilisant config-kernel pour vÃ©rifier si la permission d'Ã©crire dans
>  <path>/usr/src/linux</path> a Ã©tÃ© accordÃ©e, puis procÃ¨de Ã  l'Ã©criture si
>  demandÃ©. Cette mÃ©thode sera employÃ©e tant que la nouvelle mÃ©thode de
>  compilation ne sera pas adoptÃ©e par tous.
>  </ti>
></tr>
><tr>
>  <th>Noyau 2.6, sortie alternative</th>
>  <ti>/un/autre/chemin</ti>
>  <ti>
>  La compilation avec cette configuration nÃ©cessite l'utilisation de la mÃ©thode 
>  Â«&nbsp;koutput&nbsp;Â». Habituellement, des corrections sont requises pour les
>  makefiles, et les variables Â«&nbsp;sources&nbsp;Â» et Â«&nbsp;output&nbsp;Â»
>  seront alors rÃ©glÃ©es. Les modules compilent alors en utilisant les makefiles
>  du noyau, mais leurs fichiers de sortie sont placÃ©s dans un sous-rÃ©pertoire
>  local.
>  </ti>
></tr>
></table>
>
><p>
>Une fonction assistante est fournie par kmod.eclass pour dÃ©terminer facilement
>quelle configuration est utilisÃ©e. <b>is_koutput()</b> permet Ã  ebuild de
>dÃ©terminer comment procÃ©der Ã  la compilation. Un ebuild typique pourrait
>utiliser le test suivant&nbsp;:
></p>
>
><pre>
>	if is_koutput
>	then
>		# Utiliser sed pour corriger certaines choses pour l'utilisation de koutput.
>		sed -i "s:foo:bar:" Makefile
>	fi
></pre>
>
><p>
>La plupart des ebuilds nÃ©cessiteront un correctif pour les makefiles pour
>activer la sortie vers un rÃ©pertoire diffÃ©rent, puis l'utilisation de sed si
>is_koutput() retourne la valeur Â«&nbsp;true&nbsp;Â». L'ebuild donnÃ© comme
>exemple ci-dessous montre comment cela est gÃ©rÃ©. Pour les ebuilds nÃ©cessitant
>plus de travail (nvidia-kernel est l'un d'eux), il y a quelques fonctions qui
>peuvent Ãªtre appelÃ©es pour exercer un contrÃ´le plus fin.
></p>
>
><table>
><tr>
>  <th>Fonction</th>
>  <th>Utilisation</th>
></tr>
><tr>
>  <ti>kmod_make_linux_writable()</ti>
>  <ti>
>    Cette fonction sert Ã  permettre l'Ã©criture dans
>    <path>/usr/src/linux</path>. Elle devrait Ãªtre appelÃ©e prÃ©fÃ©rentiellement Ã 
>    l'utilisation directe de addwrite, car elle rÃ©alisera les vÃ©rifications
>    nÃ©cessaires afin d'Ãªtre sÃ»r que cela est nÃ©cessaire et que l'utilisateur
>    l'a explicitement permis avec <b>config-kernel</b>.
>  </ti>
></tr>
><tr>
>  <ti>kmod_do_buildpatches()</ti>
>  <ti>
>    Cette fonction peut Ãªtre appelÃ©e pour appliquer le correctif de
>    KMOD_KOUTPUT_PATCH lorsque nÃ©cessaire. Habituellement, elle ne sera
>    utilisÃ©e que si un ebuild est forcÃ© de dÃ©sarchiver les sources du module
>    manuellement.
>  </ti>
></tr>
><tr>
>  <ti>is_kernel()</ti>
>  <ti>
>    Cette fonction requiert deux arguments, un numÃ©ro de version majeure du
>    noyau, et un numÃ©ro de version mineure. C'est la faÃ§on recommandÃ©e de
>    vÃ©rifier si l'on utilise une certaine version du noyau.
>  </ti>
></tr>
></table>
>
><p>
>En plus de ces fonctions spÃ©ciales, kmod.eclass exporte src_unpack, src_compile,
>etc., qui peuvent Ãªtre rÃ©fÃ©rencÃ©es par kmod_src_unpack, kmod_src_compile, etc.
></p>
>
></body>
></section>
><section>
><title>Exemple de modification d'un ebuild et d'un Makefile</title>
><body>
>
><p>
>Ce qui suit est un exemple pratique dÃ©taillant comment le paquet hostap-driver
>a Ã©tÃ© modifiÃ© pour crÃ©er un ebuild tout Ã  fait fonctionnel et compatible avec
>les noyaux des sÃ©ries 2.4 et 2.6. Il utilise un correctif (assez gÃ©nÃ©ral pour
>Ãªtre utilisÃ© en amont et permettre la simplification des futurs ebuilds) pour
>le <path>Makefile</path> de plus haut niveau, ainsi que quelques changements du
>ebuild pour prendre en compte les diffÃ©rences dans les emplacements de
>certains fichiers.
></p>
>
><p>
>Vous trouverez ci-dessous des extraits du <path>Makefile</path> original, du
><path>Makefile</path> modifiÃ© et des sections modifiÃ©es qui permettent une
>compilation correcte. D'abord, une ligne doit Ãªtre corrigÃ©e car elle assume que
><path>.config</path> sera dans le mÃªme rÃ©pertoire que les sources du noyau.
></p>
>
><note>
>La variable KERNEL_OUTPUT_PATH est ajoutÃ©e plus tÃ´t dans le ebuild pour
>complÃ©menter la variable KERNEL_PATH dans l'original.
></note>
>
><pre caption="Ligne originale utilisant include">
>include $(KERNEL_PATH)/.config
></pre>
>
><p>
>La version corrigÃ©e ci-dessous permet Ã  la variable KERNEL_OUTPUT_PATH d'Ãªtre
>rÃ©glÃ©e si elle ne l'est pas dÃ©jÃ  (pour la compatibilitÃ© descendante avec 2.4)
>et cherche pour le fichier <path>.config</path> dans cet emplacement.
></p>
>
><pre caption="Ligne corrigÃ©e utilisant include">
>ifndef KERNEL_OUTPUT_PATH
>KERNEL_OUTPUT_PATH=$(KERNEL_PATH)
>endif
>
>include $(KERNEL_OUTPUT_PATH)/.config
></pre>
>
><p>
>Comme nous avons maintenant la variable KERNEL_OUTPUT_PATH Ã  notre disposition,
>corriger la dÃ©claration de variable suivante impliquant le
><path>version.h</path> gÃ©nÃ©rÃ© est simple. L'original&nbsp;:
></p>
>
><pre caption="VERFILE original">
>VERFILE := $(KERNEL_PATH)/include/linux/version.h
></pre>
>
><p>
>Et la version Ã©ditÃ©e et corrigÃ©e&nbsp;:
></p>
>
><pre caption="VERFILE Ã©ditÃ©">
>VERFILE := $(KERNEL_OUTPUT_PATH)/include/linux/version.h
></pre>
>
><p>
>Finalement, notre correctif remplace la ligne qui invoque le systÃ¨me kbuild 2.6
>afin d'incorporer l'utilisation de la variable O, paramÃ©trant le systÃ¨me pour
>produire les fichiers dans le sous-rÃ©pertoire <path>tmp/</path> du rÃ©pertoire
>courant.
></p>
>
><warn>
>kbuild s'attend Ã  trouver un fichier <path>.config</path> valide dans le
>rÃ©pertoire de sortie spÃ©cifiÃ© par <c>O=foo</c>. Le ebuild ou le makefile
>devrait Ãªtre Ã©ditÃ© pour copier <path>.config</path> dans ${KV_OUTPUT}
>(variable paramÃ©trÃ©e par kmod.eclass).
></warn>
>
><p>
>Voici l'original&nbsp;:
></p>
>
><pre caption="RÃ©pertoire de sortie original">
>$(MAKE) -C $(KERNEL_PATH) SUBDIRS=$(PWD)/driver/modules \
>	MODVERDIR=$(PWD)/driver/modules modules
></pre>
>
><p>
>Et voici la version Ã©ditÃ©e&nbsp;:
></p>
>
><pre caption="RÃ©pertoire de sortie Ã©ditÃ©">
>mkdir -p $(PWD)/tmp
>-cp $(KERNEL_OUTPUT_PATH)/.config $(PWD)/tmp
>$(MAKE) -C $(KERNEL_PATH) O=$(PWD)/tmp \
>	SUBDIRS=$(PWD)/driver/modules \
>	MODVERDIR=$(PWD)/driver/modules  modules
></pre>
>
><p>
>Les changements apportÃ©s au ebuild sont relativement simples. La eclass kmod
>rend d'ailleurs les choses trÃ¨s faciles. Voici quelques extraits de src_unpack
>et quelques variables paramÃ©trÃ©es dans le ebuild&nbsp;:
></p>
>
><pre caption="La fonction src_unpack()">
>KMOD_SOURCES="${P}.tar.gz"
>KMOD_KOUTPUT_PATCH="${PN}-koutput.diff.gz"
>
>src_unpack() {
>    # DÃ©sarchive et paramÃ¨tre quelques variables.
>    kmod_src_unpack
>	
>    ## DÃ©sarchive les sources pcmcia-cs si nÃ©cessaire.
>    pcmcia_src_unpack
>
>    epatch "${FILESDIR}/${P}.firmware.diff.bz2"
>    
>    # Si koutput est utilisÃ©, employer sed pour ajouter le chemin appropriÃ©.
>    if is_koutput
>    then
>        sed -i -e \
>	    "s:^# KERNEL_OUTPUT_PATH=.*:KERNEL_OUTPUT_PATH=${KV_OUTPUT}:" \
>	    ${S}/Makefile
>    fi
>}
></pre>
>
><p>
>Remarquez l'utilisation des deux variables, <c>KMOD_SOURCES</c> et
><c>KMOD_KOUTPUT_PATCH</c>. Ces derniÃ¨res peuvent Ãªtre rÃ©glÃ©es selon les besoins
>pour spÃ©cifier quelles sources doivent Ãªtre dÃ©sarchivÃ©es par
>kmod_src_unpack() et quel fichier de correctif employer si koutput est utilisÃ©.
><c>KMOD_KOUTPUT_PATCH</c> ne sera <b>pas</b> appliquÃ© si le processus dÃ©tecte
>que le noyau 2.6 est paramÃ©trÃ© pour utiliser <path>/usr/src/linux</path> comme
>rÃ©pertoire de sortie. Voici une version Ã©courtÃ©e de la fonction
>src_compile()&nbsp;:
></p>
>
><pre caption="Fonction src_compile()">
>src_compile() {
>    # Configurer les sources pcmcia-cs tel que nÃ©cessaire.
>    pcmcia_configure
>
>    einfo "Building hostap-driver for kernel version: ${KV}"
>    case ${KV_MINOR} in
>        [34])
>            local mydrivers
>
>            use pcmcia &amp;&amp; mydrivers="${mydrivers} pccard"
>            use hostap-nopci || mydrivers="${mydrivers} pci"
>            use hostap-noplx || mydrivers="${mydrivers} plx"
>
>            einfo "Building the following drivers: ${mydrivers}"
>            emake ${mydrivers} || die "make failed"
>            ;;
>        [56])
>            unset ARCH
>            emake all || die "make failed"
>            ;;
>        *)
>            eerror "Unsupported kernel version: ${KV}"
>	    die
>	    ;;
>    esac
>}
></pre>
>
><warn>
>Pour les noyaux 2.6, la variable <c>ARCH</c> doit ne pas Ãªtre rÃ©glÃ©e. Les
>makefiles du nouveau noyau utilisent <c>ARCH</c> pour dÃ©terminer quoi compiler
>et utilisent une syntaxe diffÃ©rente pour i386, etc.
></warn>
>
><p>
>La fonction src_install() de cet ebuild ne sera pas montrÃ©e ici, car elle ne
>fait essentiellement qu'installer tous les modules dans
><path>/lib/modules/${KV}/</path>. Notez que les changements d'extension de
><path>.o</path> Ã  <path>.ko</path> pour les noyaux 2.6 sont pris en charge.
>kmod.eclass rÃ¨gle la variable <c>KV_OBJ</c> soit Ã  <path>o</path>, soit Ã 
><path>ko</path>, tel qu'appropriÃ©, afin de simplifier les choses pour vous.
></p>
>
></body>
></section>
></chapter>
></guide>

Actions: View

Attachments on bug 48071: 29445